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Avant-propos 



Quel est lobjectif de I'ouvrage ? 

La premiere ambition de cet ouvrage est de fournir au lecteur une presentation approfondie des tech- 
nologies de services Web et de leurs implementations en J2EE et .Net. L' ouvrage couvre les techno- 
logies de base (SOAP, WSDL, UDDI), les technologies d' infrastructure (Fechange fiable, la securite, 
les transactions) et la gestion des processus metier. 

La presentation est a la fois theorique et pratique. D'un cote, les specifications sont expliquees et 
commentees en detail. Lidee est d'essayer de faire comprendre la logique architecturale qui lie 
l'ensemble, mais aussi les raisons des differents choix techniques effectues par les auteurs des speci- 
fications : ces choix sont parfois de l'ordre du detail mais ils ont des consequences importantes sur la 
mise en ceuvre des services Web. 

D'un autre cote, I'ouvrage presente la mise en ceuvre des technologies de services Web dans diffe- 
rents langages de programmation (essentiellement Java et C#, mais aussi Visual Basic, Ecmascript, 
Jscript et Flash) et sur differentes plates-formes et outils (essentiellement J2EE et .Net, mais aussi 
Internet Explorer, Mozilla, Office XP, Flash). La presentation est toujours agrementee d'exemples et 
la derniere partie de I'ouvrage decrit une etude de cas, au contenu fonctionnel intuitif, declinee en 
plusieurs variantes en termes d' architecture technique et d' implementation, qui demontrent les diffe- 
rentes facettes et usages des technologies de services Web. 

Tous les logiciels des exemples et de 1' etude de cas sont executables et les codes source sont disponibles 
en telechargement libre sur le site des Editions Eyrolles (http://www.editions-eyrolles.com). 

L ouvrage ne presente pas systematiquement, pour chaque « brique » de la technologie des services 
Web, plusieurs implementations concurrentes disponibles (J2EE, Net, autre plate-forme). Cepen- 
dant, maintenir une position de neutralite en traitant des plates-formes d' implementation a ete une de 
nos principales preoccupations et nous avons essaye de garder, dans la mesure du possible, un equili- 
bre entre les implementations sur les differentes plates-formes. Par exemple, pour F interface 
programmatique UDDI, c'est F implementation en Java qui est presentee, tandis que F implementation 
de la securite est presentee essentiellement en .Net (C#). 

L'avantage (et Fobjectif) essentiel des technologies de services Web etant Finteroperabilite, nous 
F avons demontre dans maints cas par la mise en ceuvre de plusieurs exemples et de variantes de 
Fetude de cas sur des plates-formes mixtes. Linteroperabilite empiriquement verifiable est aussi une 
demonstration concrete du decouplage entre une architecture de services Web et son implementation 
logicielle, cette derniere etant banalisee et interchangeable. 
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La deuxieme ambition de cet ouvrage est de presenter concretement les technologies de services Web 
comme le support d'election du modele emergent de 1' architecture orientee services. 

Nous sommes convaincus que les technologies des services Web vont devenir un vecteur de change - 
ment et d'automation des processus metier intra et interentreprises. Elles vont aussi changer les prati- 
ques et le positionnement des professionnels de l'informatique, a Finterieur des organisations et sur 
le marc he. 

Nous ne nous hasardons pas a traiter les consequences socio-economiques de 1' adoption de la techno- 
logie qui fait Fobjet de cet ouvrage. En revanche, nous essayons de montrer, par la pratique, F archi- 
tecture orientee services comme un nouveau paradigme qui implique un changement d'approche de 
la part des informaticiens : changement dans la relation avec les utilisateurs mais aussi changement 
dans la maniere de penser, concevoir, developper, deployer et exploiter les logiciels et les systemes 
repartis. 

Pour mettre en evidence le nouveau paradigme, la premiere partie de Fouvrage est consacree a une 
presentation circonstanciee du modele de F architecture orientee services. La deuxieme partie 
presente les technologies de base (SOAP, WSDL, UDDI). La troisieme partie expose les differentes 
plates-formes d' implementation (J2EE, .Net, autre). La quatrieme partie approfondit les specifica- 
tions et les implementations des technologies d' infrastructure (fiabilite de Fechange, securite, gestion 
des transactions) ainsi que la mise en ceuvre des processus metier par des langages de scenario 
(BPEL...). La cinquieme partie presente P etude de cas (un service d'agence de voyages implemente 
par agregation de differents services de reservation), decline en plusieurs variantes : d'une architec- 
ture quasi-statique a la mise en ceuvre en processus metier BPEL, en passant par des architectures 
dynamiques avec UDDI. Une description plus detaillee du contenu de Fouvrage, chapitre par chapitre, 
est donnee au chapitre 1 . 

A qui s'adresse cet ouvrage ? 

Cet ouvrage s'adresse : 

• aux developpeurs d' applications, et plus particulierement a ceux qui utilisent les environnements 
J2EE et .Net ; 

• aux architectes des systemes d' information, qui souhaitent comprendre les concepts cles de 
Farchitecture orientee services (AOS) et de sa mise en ceuvre ; 

• aux decideurs, consultants, chefs de projets et specialistes de V integration, qui ont besoin 
d'etendre leur capacite d' intervention vers F urbanisation du SI de Fentreprise et la prise en charge 
de services a valeur ajoutee ; 

• aux etudiants des ecoles d'ingenieurs et universitaires, qui recherchent une reference sur ce type 
d' architectures. 
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La premiere difflculte a laquelle on se heurte lorsqu'on aborde le vaste sujet des technologies de 
services Web est d'ordre terminologique. Un exemple, desormais bien connu, du desordre terminolo- 
gique est le vrai faux acronyme SOAP, qui signifierait « Simple Object Access Protocol », alors qu'il 
designe un protocole d'echange entre applications reparties - ou il n'est nulle part question d'acceder 
a des « objets ». Le debat a finalement ete tranche par le W3C, qui a d'autorite supprime la forme 
developpee du terme « SOAP », dont il a simplement fait un nom propre. 

Les difficultes commencent, a vrai dire, avec le terme meme de « service Web » (Web service) : 
George Colony, fondateur et CEO de Forrester Research Inc., dans sa conference du 10 mars 2003 au 
ICT World Forum {http://idg.net/ic_1211529_9677_1-5041.html) dit a propos des services Web qu'il n'est 
absolument pas question de « services » ni de « Web », mais que la denomination la plus appropriee 
serait celle de « middleware Internet » qui permet de connecter les applications des entreprises a 
celles de leurs clients et partenaires. 

II est vrai que le terme de « service » est galvaude, que le terme « Web » evoque les sites Web, et que 
les deux termes juxtaposes font penser a des services pour le public et les professionnels, pourvus par 
des sites Web, ce qui est deroutant par rapport au concept de services Web. Tous ceux qui, comme les 
auteurs, ont anime des conferences et des presentations sur le sujet peuvent temoigner de la difflculte 
a articuler les messages les plus simples en raison de l'usage detourne de ces termes. Par exemple, il 
faut rappeler sans cesse le fait que cette technologie preside a l'echange direct des applications entre 
elles sans la participation ni 1' intermediation des utilisateurs. 

Cela dit, meme si la proposition de George Colony a l'avantage d'etre claire, nous ne sommes pas 
entierement d' accords avec lui sur deux points : 

• Le terme de middleware doit etre manie avec precaution, car il evoque le deploiement dans une 
architecture repartie d'un ensemble de composants technologiques coherents, elements du meme 
produit. Or, il n'y a pas de produit a deployer, mais plutot des specifications de langages de 
description (comme WSDL) et de protocoles d' interaction (comme SOAP) que chacun peut 
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implemented dans son environnement technique, par des composants logiciels standards ou bien 
specifiques, proprietaries ou bien ouverts. C'est la conformite aux specifications de ces composants 
qui permet V interoperabilite des applications, objectif primaire de la technologie des services 
Web, et le middleware en question, autant qu'on puisse Fappeler ainsi, est done mis en ceuvre par 
l'interaction dynamique de composants d'origines diverses et d' implementations heterogenes. 

• A F inverse, le terme de « service », bien que souvent employe dans des acceptions plus precises, 
reste pertinent et important. L' utilisation de ce terme permet de rattacher la technologie des 
services Web a V architecture orientee services. L' architecture orientee services est un concept et 
une approche de mise en ceuvre des architectures reparties centree sur la notion de relation de 
service entre applications et sur la formalisation de cette relation dans un contrat. L' architecture 
orientee services est en principe un concept independant de la technologie des services Web, mais 
cette derniere represente desormais son plus important moyen d' implementation et fournit la base 
technologique pour sa diffusion sur une echelle jamais experimentee auparavant. Le langage 
WSDL (Web Services Description Language) en est la technologie pivot qui represente le noyau 
extensible d'un langage de formalisation de contrats de service entre applications. 

Ces precisions faites, en conformite avec un usage desormais assez repandu, nous continuerons a 
appeler les technologies presentees dans cet ouvrage, technologies de services Web en sachant que le 
terme va rapidement se banaliser comme un nom propre (si ce n'est pas deja fait). Par ailleurs, nous 
utiliserons aussi le terme de service Web pour designer une application qui joue le role de prestataire 
dans une relation de service et est mise en ceuvre sur la base de la technologie des services Web. 

Cet ouvrage tente de presenter un panorama large et organise de ces technologies et de leurs imple- 
mentations en J2EE et .Net, tout en offrant un approfondissement des problemes fondamentaux poses 
par leur deploiement et leur evolution, avec a la cle des exemples d' application et une etude de cas 
dont 1' implementation est declinee en plusieurs variantes. 

Louvrage, outre cette introduction et une conclusion est organise en vingt-cinq chapitres regroupes 
en cinq parties. La premiere partie (chapitres 2, 3 et4) traite de F architecture orientee services. La 
deuxieme partie (chapitres 5, 6, 7, 8, 9, 10, 11 et 12), apres un rappel des technologies Internet et 
XML, introduit les technologies cles SOAP, WSDL et UDDI. La troisieme partie (chapitres 13, 14, 
15, 16 et 17) presente les plates-formes d' implementation J2EE et .Net, ainsi que les composants 
disponibles sur le poste de travail et traite les problemes d'interoperabilite. La quatrieme partie 
(chapitres 18, 19, 20 et21) introduit les technologies d' infrastructure qui garantissent l'echange 
fiable, la gestion de la securite et la gestion des transactions, ainsi que la gestion des processus metier. 
La cinquieme et derniere partie (chapitres 22, 23, 24, 25 et 26) decline une etude de cas en plusieurs 
architectures a configuration statique et dynamique, sur plate-forme Java et .Net, ainsi que F applica- 
tion du langage de scenarios de processus metier BPEL. 

Nous pensons que la matiere traitee est suffisante pour donner au lecteur une vision a la fois large et 
approfondie de F architecture orientee services et de la technologie des services Web. Par ailleurs, le 
developpement de la technologie des services Web avance a grands pas et touche des domaines et des 
sujets qui ne sont pas traites dans cet ouvrage pour des questions d'espace et d'unite d'eeuvre. Le 
chapitre de conclusion evoque les axes centraux de consolidation et de developpement futur des 
services Web, et quelques idees d'exploration sur des sujets non traites. 
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L'architecture orientee services 

Nous avons pris le parti de considerer que la declinaison du concept d' architecture orientee services 
(chapitres 2, 3 et 4) etait le meilleur moyen pour introduire le cadre conceptuel et la terminologie 
utilise dans la suite de l'ouvrage. La technologie des services Web est done presentee comme le 
moyen d' implementation des architectures orientees services. La premiere partie fournit la cle de 
lecture qui permet de comprendre la position et le role fonctionnel des differents modules techno- 
logiques presentes dans la deuxieme et la quatrieme partie, ainsi que des implementations presentees 
en troisieme partie. 

Le chapitre 2 introduit le concept d' architecture orientee services. II introduit la relation de service 
et les roles de clients et de prestataires joues par les applications participates. II est important de 
noter que nous avons choisi le terme « prestataire » pour marquer une difference avec la terminologie 
des architectures client/serveur, qui ne sont qu'une forme specifique et limitee des architectures 
client/prestataire. II introduit egalement la notion de contrat, lequel formalise les engagements du 
prestataire et eventuellement du client dans la realisation de la prestation de services. 

Un contrat est un document organise en plusieurs parties, dont les plus importantes sont : 

• la description des fonctions du service ; 

• la description de V interface du service ; 

• la description de la qualite du service. 

Le chapitre 2 presente les fonctions et F interface dans le contrat de service. II faut bien noter la diffe- 
rence entre les fonctions et 1' interface du service : la description des fonctions est une description 
abstraite de la prestation de services, tandis que F interface est une description des mecanismes et des 
protocoles de communication avec le prestataire de services. Naturellement, la comprehension du 
lien entre F interface et les fonctions d'un service est capitale. Le probleme de la formalisation de ce 
lien n'a pas encore de solution satisfaisante aujourd'hui, tout au moins a Fechelle ou ce probleme est 
pose par la diffusion des technologies des services Web. 

Si la description fonctionnelle est abstraite et independante de F implementation du prestataire, la 
description de Finterface s'etend jusqu'aux details concrets comme les protocoles de transport des 
messages et les adresses des ports de reception. 

Le chapitre 3 traite de la qualite de service, e'est-a-dire de Fensemble des proprietes operationnelles 
(non fonctionnelles) d'un service : performance, accessibilite, fiabilite, disponibilite, continuite, 
securite, exactitude, precision... La formalisation et la prise en charge explicite d'engagements de 
qualite de service est de facon generate encore insuffisamment, voire pas du tout, traitee dans le cadre 
des technologies des services Web. La qualite de service va prendre une importance croissante avec 
la diffusion d' architectures orientees services de plus en plus larges et dynamiques. Les engagements 
de qualite de service vont constituer un facteur de differentiation importante entre les prestataires 
fournissant le meme service du point de vue fonctionnel. 

Le chapitre 3 se termine par une discussion des relations entre le contrat de service et la mise en 
ceuvre concrete des applications clientes et prestataires agissant en conformite avec le contrat. II 
etablit notamment la relation entre les differentes parties du contrat et les langages et protocoles des 
technologies de services Web. Par ailleurs, lors de la presentation (dans les chapitres 2, 3 et 4) de 
chaque element du contrat, qu'il soit fonctionnel, d' interface ou operationnel, l'ouvrage renvoie 
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systematiquement a la technologie de services Web censee decrire formellement l'engagement 
contractuel ou bien le mettre en ceuvre. 

Le chapitre 4 traite des architectures orientees services a configuration dynamique. Pour introduire 
le sujet, il presente tout d'abord deux « figures » de la demarche de conception et de mise en ceuvre 
de F architecture orientee services : 

• V agregation de services ; 

• la dissemination de services. 

L' agregation est la realisation d'un service qui integre, pour realiser sa prestation, les resultats des 
prestations d'autres services. La dissemination est, a Finverse, la mise en ceuvre sous forme de servi- 
ces modulaires des fonctions d'une application monolithique. La conception d'une architecture 
orientee services est en general le resultat de la combinaison de ces deux demarches. 

L aspect dynamique de la configuration de 1' architecture n'est ni secondaire ni accessoire, mais bien 
au cceur meme du concept d' architecture orientee services (ce qui n'empeche pas par ailleurs de 
mettre en ceuvre des architectures orientees services totalement statiques). Dans une architecture 
dynamique, les services qui la composent, les applications prestataires qui interviennent, ainsi qu'un 
certain nombre de proprietes operationnelles des prestations de services ne sont pas definis avant sa 
mise en place, mais sont composes, configures, etablis, voire negocies, au moment de l'execution. Ce 
processus peut etre iteratif : il est possible de reconfigurer une architecture dynamique a la volee lors 
de son fonctionnement normal, ou bien a l'occasion d'un dysfonctionnement. 

Avec les technologies de services Web disponibles actuellement, on peut notamment etablir des archi- 
tectures dans lesquelles les applications participates peuvent choisir dynamiquement les services 
« abstraits » qu'elles consomment, les prestataires de ces services, les ports d'acces de ces prestataires. 
L etude de cas presente dans la cinquieme partie articule la meme application repartie en plusieurs 
scenarios d' architectures douees de niveaux differents de capacite de configuration dynamique. 
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La deuxieme partie (chapitres 5, 6, 7, 8, 9, 10, 1 1 et 12), apres un rappel des bases et des fondements 
(les protocoles Internet et le langage XML) presente les trois technologies cles des services Web : 
SOAP, WSDL et UDDI. 

II est evident que, sans Internet, Fensemble des technologies de services Web ne serait encore qu'un 
autre standard de middleware, un nouveau concurrent de DCOM ou de CORBA. A Finverse, certains 
fournisseurs qui ont un pare important de produits proprietaires installes pretendent que, sur des 
reseaux locaux ou proprietaires, il est possible de deployer des architectures de services Web qui 
n'utilisent pas de protocoles de communication Internet, mais des middlewares patrimoniaux. Cette 
« mouvance » definit un service Web comme une application dont 1' interface est decrite par un docu- 
ment WSDL, independamment de la technologie de middleware utilisee pour interagir avec elle. En 
revanche, le deploiement de ces merries architectures sur Internet impose F utilisation de protocoles 
Internet et notamment d'HTTP, qui se detache aujourd'hui comme le premier protocole de transport 
pour la communication avec les services Web. Le chapitre 5 rappelle les fondamentaux des concepts 
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et protocoles Internet (URI et URL, HTTP, SMTP, MIME, SSL, TLS) ainsi que le modele de refe- 
rence en sept couches OSI de F International Standard Organisation. 

Le chapitre 6 est un rappel indispensable de ce que sont XML et les technologies connexes comme 
XML Namespaces, Xlink, Xpath, XML Base, XML Schema et DOM. Les technologies XML consti- 
tuent une veritable fondation pour les technologies de services Web : XML est a la base du format de 
message SOAP et du langage de description WSDL. 

XML Namespaces et XML Schema sont particulierement utilisees par les services Web. XML 
Namespaces est l'outil de gestion des versions et permet de gerer sans conflit Fassemblage et l'exten- 
sion de technologies et d' applications d'origines differentes. Quant a XML Schema, il est specifie 
d'emblee comme seul outil de definition de formats XML dans les services Web. Les DTD n'ont pas 
cours dans le monde des services Web : il est meme explicitement interdit, par exemple, de vehiculer 
une DTD comme partie d'un message SOAP. 

Ces rappels sont faits avec le simple objectif d'epargner au lecteur, qui a deja une certaine familiarite 
avec la matiere, la necessite de quitter l'ouvrage pour un rappel rapide ou un renseignement ponctuel 
et ne remplacent en aucun cas les ouvrages specialises sur le sujet. 

SOAP, qui est Fobjet des chapitres 7, 8 et 9, va inevitablement devenir le protocole d'echange utilise 
pour communiquer avec les services Web, bien qu'en principe il ne soit pas le seul protocole admis. Le 
chapitre 7 introduit les fondamentaux du protocole (le format de message, le message d'erreur, le style 
d'echange « message a sens unique ») et presente en outre rapidement la problematique des chaines 
d'acheminement {routing) : en fait, SOAP est basiquement concu pour permettre d'interposer entre 
l'expediteur et le destinataire une chaine d'intermediaires qui sont, potentiellement, des fournisseurs de 
services annexes comme la securite et la non-repudiation. Lutilisation d'une chaine d'acheminement reste 
une possibility qui peut etre mise en ceuvre comme une extension « proprietaire » du protocole SOAP 
(c'est l'option choisie par Microsoft avec la specification WS-Routing) en attendant une specification 
du mecanisme qui puisse aspirer au statut de standard. 

La demarche mise en ceuvre pour les chaines d'acheminement est typique de l'approche courante du 
developpement des specifications des technologies de services Web : 

• les specifications de base (SOAP, WSDL) contiennent un mecanisme standard d' extension ; 

• les promoteurs d'une technologie de niveau « superieur » (par exemple la fiabilite des echanges, la 
securite, les transactions) utilisent les mecanismes standards d'extension pour proposer des speci- 
fications : dans cette phase, on peut assister a la parution de plusieurs propositions concurrentes ; 

• un acteur institutionnel (W3C, OASIS) est saisi de la tache de batir une norme unifiee sur la base 
d'une ou plusieurs propositions concurrentes. 

La troisieme etape n'est evidemment pas automatique, mais resulte des negotiations conduites « en 
coulisses » entre les acteurs technologiques majeurs. 

Le chapitre 8 presente le sujet tres controverse du codage des donnees dans un message SOAP. 
Le sujet est complexe pour plusieurs raisons que nous analysons en detail dans ce chapitre : 

• les principaux langages de programmations manipulent des structures de donnees partagees et 
circulaires (par exemple des graphes d'objets) ; 
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• pour pouvoir transferer ces structures, il faut un mecanisme pour les serialiser dans un fragment 
XML, partie d'un message SOAP ; 

• la representation lineaire de ces structures ne peut pas etre definie par l'utilisation standard d'XML 
Schema. 

La specification SOAP 1 . 1 propose un mecanisme de codage dont le resultat peut etre valide par un 
analyseur syntaxique XML standard mais demande la mise en ceuvre d'un mecanisme specifique 
capable de reconstruire la structure partagee ou circulaire en memoire. La discussion dans la commu- 
naute est tres vive : l'organisme de validation d'interoperabilite des implementations des technolo- 
gies des services Web (WS-I) interdit, pour cause de defaut d'interoperabilite, l'utilisation du meca- 
nisme de serialisation (dit style de codage SOAP) car il n'est pas mis en ceuvre de facon homogene, 
et dans la specification SOAP 1.2 (qui n'est pas encore adoptee comme recommandation par le W3C) 
la mise en ceuvre du style de codage est consideree comme optionnelle. Le codage permettant la 
serialisation/deserialisation de structures partagees ou circulaires est cependant necessaire pour 
« coller » aux applications patrimoniales des interfaces de services Web sans modifier leurs API 
(Application Programming Interface), car ces dernieres presentent parfois des invocations de methodes 
et des procedures vehiculant « par valeur » des structures de ce type. 

Le chapitre 8 presente par ailleurs la specification contenue dans la note W3C SOAP Messages with 
Attachments qui permet d'inclure dans la meme requete ou reponse HTTP un message SOAP et des 
objets binaires (images, documents pdf, documents Word...) considered comme des pieces jointes, 
tout en permettant de referencer ces pieces de Finterieur du message. Nous ne presentons pas la 
specification concurrente (DIME) d'origine Microsoft, qui est posterieure mais semble rester confi- 
nee dans le monde Microsoft. 

Le chapitre 9 decrit plus en detail les styles d'echange propres au protocole SOAP. En fait, SOAP 
propose deux styles d'echange : le message a sens unique et la requete/reponse. Le deuxieme style ne 
peut etre mis en ceuvre que sur un protocole de transport bidirectionnel comme HTTP, a savoir sur un 
protocole de transport qui se charge lui-meme de la correlation entre la requete et la reponse. La 
correlation entre messages transferes par des protocoles unidirectionnels (comme SMTP) peut bien 
entendu etre realisee, mais via des extensions, a savoir l'utilisation d'identifiants de messages contenus 
dans Fen-tete. 

Le chapitre 9 decrit la liaison SOAP/HTTP, c'est-a-dire F ensemble des regies qu'il faut respecter 
pour transferer correctement des messages SOAP via le protocole HTTP. La presentation de la liaison 
permet egalement d'introduire la problematique de l'asynchronisme dans l'envoi et le traitement des 
messages. 

Le style d'echange requete/reponse en SOAP se decline en deux variantes : le style document et le 
style rpc. Dans le style document, la requete et la reponse SOAP n'ont pas une structure differente de 
celle d'un message SOAP standard. En style ipe, la requete et la reponse ont une structure parti- 
culiere qui permet d'utiliser le message et le protocole SOAP pour serialiser l'appel et le retour 
d'appel de procedure distante. Le style rpc est notamment indispensable pour exposer comme inter- 
face de service Web F API d'une application patrimoniale avec un minimum d'effort. 

Le chapitre 10 presente WSDL (Web Services Description Language). WSDL est Foutil pivot de la 
technologie des services Web car il permet veritablement de donner une description d'un service Web 
independante de sa technologie d'implementation. Les traits principaux du langage sont presentes via 
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l'exemple d'un des services Web les plus populaires : l'acces programmatique par SOAP ail moteur 
de recherche Google (http://www.google.com/apis). 

Un document WSDL joue le role d'embryon de contrat de service et represente done le document de 
reference pour les equipes cote « client » et cote « prestataire ». II joue en outre un role technique 
pivot car il peut etre : 

• genere automatiquement a partir d'une application par des outils souvent integres aux environnements 
de developpement ; dans ce cas, la formalisation du service derive directement de la conception de 
F interface d'une application ; 

• ou bien etre l'input de la generation de proxies et de skeletons, a savoir de code qui, integre avec le 
code applicatif, permet a une application de jouer respectivement le role de client et de prestataire 
de services. 

Le chapitre 10 presente quelques outils disponibles pour effectuer ces deux operations. Ces outils 
sont bien sur decrits plus avant dans les chapitres de la troisieme partie de l'ouvrage et leur utilisation 
est montree en detail dans l'etude de cas en cinquieme partie. 

Les chapitres 11 et 12 presentent UDDI (Universal Description, Discovery and Integration), la 
specification d'un service d'annuaire expressement dedie a la decouverte et a la publication de services 
Web. UDDI est egalement realise comme un service Web (1' interface est decrite en WSDL et Faeces 
aux annuaires publics et prives est mis en ceuvre en SOAP sur HTTP). 

UDDI n'est pas seulement une specification d'annuaire accompagnee de quelques implementations 
(qui peuvent etre utilisees pour mettre en ceuvre ce que Ton appelle des annuaires prives, a l'interieur 
d'une entreprise ou d'une communaute de partenaires) : e'est aussi le support d'un systeme reparti 
d' annuaires publics repliques qui permettent la publication et la decouverte de services sur Internet. 
Ce systeme reparti appele UBR (UDDI Business Registry) est mis en ceuvre par un groupe de four- 
nisseurs, dont Microsoft et IBM, qui etaient parmi les promoteurs de la specification. 

La specification UDDI distingue deux parties de 1' interface d'acces : 1' interface en lecture (inquiry) 
qui permet la recherche et la decouverte de services Web, et 1' interface de mise a jour (publication) 
qui permet la mise a jour de l'annuaire avec l'ajout de nouveaux services et la modification de servi- 
ces existants. Le chapitre 1 1 presente, via des exemples concrets d'interaction avec l'UBR realises en 
code executable Java, les primitives de recherche et de lecture. Le chapitre 12, illustre, toujours au 
moyen d'exemples d'interaction avec l'UBR, les primitives de publication. Dans l'etude de cas 
(cinquieme partie), deux architectures dynamiques differentes (Java et .NET) sont illustrees a l'aide 
d'un annuaire UDDI prive. Le code source de tous les exemples des chapitres 1 1 et 12 est disponible 
en telechargement libre sur le site d'accompagnement du livre, a l'URL http://www.editions-eyrolles.com. 

L'annuaire UDDI offre aujourd'hui (version 2.0 et suivantes) la possibilite de definir des relations 
complexes entre prestataires de services (par exemple de type organisationnel ou de partenariat) ainsi 
que des possibilites de categorisation et d'indexation des services et des prestataires en coherence 
avec les differentes taxinomies et les divers systemes de codification utilises couramment par les 
entreprises dans les differents secteurs economiques. 
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Les plates-formes operationnelles 

La troisieme partie (chapitres 13, 14, 15, 16 et 17) est consacree a la description d'un certain 
nombre d' implementations de technologies de services Web. En fait, nous presentons les differentes 
plates-formes Java/J2EE (chapitre 14) et la plate-forme Microsoft .Net (chapitre 15), ainsi qu'un 
certain nombre d' implementations sur le poste de travail qui permettent a des applications locales, 
eventuellement telechargees a la volee, de jouer le role de client de services Web (chapitre 16). Ces 
presentations sont precedees du chapitre 13 qui resume les principes de la demarche de developpe- 
ment des elements d'une architecture de services Web (les clients, les prestataires), et suivies du 
chapitre 17, lequel traite du probleme de l'interoperabilite effective entre implementations heterogenes. 

Les principes de mise en ceuvre des elements d'une architecture de services Web (chapitre 13) sont 
independants des environnements de developpement et d' exploitation choisis. II est parfois surpre- 
nant de constater la fondamentale homogeneite de la demarche, que Ton soit en Java, .Net ou meme 
sur d'autres environnements plus peripheriques. Cette demarche varie selon la perspective dans 
laquelle on se situe : le chapitre 13 decrit les differentes methodes de developpement qui peuvent etre 
appliquees selon que Ton se place du point de vue du prestataire d'un service ou de celui du client de 
ce service. La fin du chapitre presente quelques-unes de ces methodes et montre qu'en fait la mise en 
ceuvre des elements d'une architecture de services se reduit a la combinaison d'un nombre restreint 
de taches unitaires : 

• la transformation d'un composant applicatif existant en un service, avec generation WSDL a la 
cle ; 

• la generation d'un proxy a partir d'une description WSDL d'un service, a integrer dans le client du 

service ; 

• la generation d'un squelette (skeleton) de prestataire, toujours a partir d'une description WSDL 
d'un service ; 

• la generation d'un client de test d'un service, toujours a partir d'une description WSDL. 

De cette liste de taches se degage encore une fois le role primordial joue par la description WSDL. 
veritable pivot de toute action de developpement. Les schemas de ces differentes taches ne sont pas 
seulement decrits, mais sont mis en ceuvre sur des exemples, a l'aide de differents outils de develop- 
pement, en environnements .Net et J2EE. 

Le chapitre 14 presente les environnements Java/J2EE. II debute par une description des produits de 
l'organisation Apache, c'est-a-dire de F implementation Java SOAP4J qui est consideree comme la 
reference de facto, ainsi que d' outils complementaires tels Xerces et Tomcat, et du nouveau serveur 
dereference Axis. 

En raison de la richesse et de l'heterogeneite de l'offre Java, nous avons pris le parti de donner dans 
le chapitre 14 un large panorama des acteurs du monde Java et de revolution de leurs offres : 

• IBM et BEA jouent dans la categorie des acteurs ayant deja une presence etablie dans les systemes 
informatiques des entreprises, avec des composants qui se situent dans le prolongement direct des 
offres respectives de serveurs d' applications (WebSphere, WebLogic). 

• Tandis qu'IBM peut se targuer d'avoir ete, avec Microsoft, a l'origine de la technologie des 
services Web et de rester aujourd'hui un acteur majeur avec WebSphere, Hewlett-Packard joue le 
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role surprenant du visionnaire (l'offre e-Speak, qui correspondait a des services Web avant les 
services Web, etait remarquablement coherente et developpee) qui abandonne le marche des outils 
de developpement et des serveurs d' applications pour se concentrer sur ses competences en admi- 
nistration de systemes repartis et les appliquer aux besoins du naissant Web Services Management. 

• Sun Microsystems conduit des actions sur differents niveaux, comme la normalisation des imple- 
mentations du monde Java dont elle a la maitrise via le mecanisme des JSR, qui doit tenir compte 
du standard de fait SOAP4J de Apache, et la mise a jour de l'offre SUN ONE. 

A cote de ces acteurs historiques, et d'autres comme Oracle, Novell ou IONA Technologies qui ont 
un role pour F instant moins marque (sauf IONA qui voit son offre sur les services Web comme le 
prolongement naturel de sa maitrise de la technologie CORBA et propose un outillage assez 
complet), un certain nombre d' acteurs totalement nouveaux (The Mind Electric, Cape Clear, Systi- 
net, Bowstreet, Collaxa, PolarLake, Alto Web, Sonic Software) se sont positionnes avec des produits 
interessants. En fin de chapitre, une liste complete de sites de reference et de ressources est proposee 
au lecteur. 

Le chapitre 15 decrit, avec un niveau de detail important, Fenvironnement d' execution Microsoft 
.Net, l'environnement de developpement Visual Studio et la mise en ceuvre des technologies des 
services Web dans ces environnements. Contrairement a l'environnement Java, preexistant a la paru- 
tion des technologies de services Web, .Net est ne en meme temps, Microsoft ayant comme objectif 
explicite de rendre le maniement d'XML et la mise en place de services Web a la portee d'un proces- 
sus de developpement « sans peine ». L'integration entre .Net, Visual Studio, le langage XML et les 
technologies des services Web est effectivement tres poussee. Ce chapitre presente les differents 
elements de l'environnement, a commencer par le CLR (Common Language Runtime) et les librai- 
ries d'objets de base, en passant par le langage C#, ASP .Net et les Web Forms pour terminer sur la 
generation assistee d'un service Web et d'un proxy en C#. 

Le chapitre 16 presente des technologies de differentes origines qui permettent de developper des 
applications sur le poste de travail. La cible de ce type d' applications est particulierement large : 
plusieurs analystes, partant du constat des limitations severes quant a la puissance et l'ergonomie que 
les technologies navigateur et HTML imposent aux interfaces homme/machine, font la prevision de 
Farrivee d'une nouvelle generation de logiciels et d' applications sur le poste client capables de 
depasser ces limitations. La possibilite d'executer dans le cadre d'un navigateur (Internet Explorer ou 
Mozilla) du code telechargeable (en JavaScript ou Ecmascript) qui met en ceuvre F interaction avec 
les services Web via SOAP ouvre des perspectives tres interessantes pour une nouvelle generation 
d' applications. 

De meme, la possibilite de programmer en Visual Basic des logiciels bureautiques (tels qu'MS 
Word XP ou MS Excel XP), pour qu'ils puissent acceder directement a des services Web distants, 
change les perspectives de developpement d' applications dans des domaines importants comme la 
gestion documentaire ou la gestion financiere. L'utilisateur n'a pas a quitter son environnement de 
travail habituel pour interagir avec les applications et les bases de donnees de Fentreprise : c'est « de 
Finterieur » de ses outils qu'il peut ramener des donnees sur le poste de travail, les visualiser sous la 
forme habituelle d'un texte ou d'un tableur et eventuellement sauvegarder sur les serveurs d'entre- 
prise le resultat de son travail local simplement par un bouton d'interface. Le chapitre presente un 
exemple concret et detaille de programmation d'Excel XP en Visual Basic (cette derniere application 
permet d'interroger le service Web Google et de produire les resultats d'une recherche dans un 
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tableau Excel). Le chapitre se termine par un exemple d'utilisation du composant de services Web de 
Macromedia Flash qui montre comment une animation locale peut se nourrir de donnees recuperees 
periodiquement aupres de services Web distants. 

Le code-source de tous les exemples du chapitre 16 est disponible en telechargement libre sur le site 
d'accompagnement du livre, a l'adresse http://www.editions-eyrolles.com. 

La troisieme partie est close par le chapitre 17, qui porte sur les moyens que la communaute de deve- 
loppement des services Web se donne pour tester 1'interoperabilite effective entre implementations 
heterogenes et sur les resultats obtenus par cette demarche. Le probleme de l'interoperabilite est bien 
le paradoxe des technologies des services Web : d'un cote elle est l'objectif principal et de l'autre un 
defi qu'il faut relever sans cesse. Ce qui est remarquable et nouveau (par rapport, par exemple, a la 
demarche de l'OMG sur CORBA et l'OMA), est que la communaute des developpeurs s'est preoccu- 
pee de l'interoperabilite effective des implementations des le debut et a mis en place des organisa- 
tions, des demarches et des outils pour promouvoir, ameliorer, controler et tester le niveau effectif 
d'interoperabilite. 

II faut noter que cette activite est non seulement bien differenciee de l'activite de specification, mais 
aussi du controle de conformite des implementations par rapport aux specifications. En fait, elle ne 
porte pas de jugement sur la conformite aux specifications des implementations prises separement, 
mais constate leur capacite a interoperer entre elles (en appliquant, par exemple, a chaque couple 
d' implementation le meme cas de test et en dressant la matrice des resultats). Du coup, cette activite 
produit egalement une critique empirique des specifications lorsqu'un element de ces specifications 
est l'objet d'echecs repetes d'interoperabilite. La communaute de developpement s'est done dotee de 
plusieurs batteries de test sur les differentes technologies (SOAP, WSDL), effectue ces tests par 
rounds et en publie les resultats. Une organisation exclusivement dediee a promouvoir, tester et 
controler l'interoperabilite a ete creee par les principaux acteurs (WS-I). Le chapitre presente l'avan- 
cement de ces travaux et leurs resultats. 



U infrastructure des services Web 

La quatrieme partie de l'ouvrage reprend le tableau general de l'architecture des technologies des 
services Web tel que laisse a la fin de la troisieme partie, ou nous avons presente la premiere 
« couche » (le protocole d'echange SOAP, le langage de description WSDL et le service d'annuaire 
UDDI). 

La question que les utilisateurs se posent est la suivante : la disponibilite d' implementations fiables 
de la premiere couche constitue-t-elle une condition suffisante a la mise en place d' architectures de 
services Web suffisamment performantes et robustes pour prendre en charge les processus metier par 
lesquels l'entreprise coopere avec ses clients et partenaires ? La reponse a la question n'est pas 
immediate et nous conduit a nuancer nos propos. 

Avec la vague Internet, l'entreprise a commence par se presenter sur le Web (site institutionnel stati- 
que), puis elle a appris a communiquer sur le Web (site a gestion dynamique de contenu) et enfin a 
rendre accessible une partie de ses processus operationnels via le Web (sites « trans actionnels », sites 
de commerce electronique, sites B2B ou business to business). Ce sont evidemment ces dernieres 
applications, surtout dans le domaine du B2B, qui sont les plus concernees par la technologie des 
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services Web. L'idee est simple : doubler Faeces actuel ail processus de la part d'un utilisateur 
professionnel (appartenant a une organisation cliente ou partenaire) au moyen d'un navigateur, par un 
acces par programme via une interface de service Web. Cette « doublure » est-elle realisable avec les 
technologies de la premiere couche ? 

En fait, tout ce qu'un utilisateur fait manuellement a l'aide d'un navigateur peut etre realise par un 
programme via une interface de service Web : il n'y a aucune degradation de securite. L'utilisation de 
SSL/TLS se fait dans les deux cas exactement de la meme maniere et le danger de la saturation des 
appels qui conduit au denial of service n'est pas plus fort pour un service Web que pour un site Web. 
Les fonctions offertes par le service peuvent etre, en premiere instance, exactement les merries que 
celles offertes par le site. Les outils disponibles, pour peu que 1' application dispose d'une API utili- 
sable, permettent la generation quasi-automatique du service et de sa description WSDL (qui peut 
etre utilisee par les clients potentiels pour une generation pratiquement automatique des proxyservices). 
L operation de creation, pour un site Web donne, d'un service Web iso-fonctionnel, peut etre effectuee 
(s'il n'y a pas de problemes caches) avec un effort quasiment nul. 

La dimculte doit etre cherchee plutot du cote « client », dans la maitrise de la « defaillance partielle » 
propre a toute architecture repartie, a commencer par la plus simple qui est le client/serveur tradition- 
nel. Le « client » d'un site Web, derriere un navigateur, est un acteur humain : son intelligence est 
sollicitee non pas lorsqu'il remplit banalement un formulaire (un programme serait certainement plus 
rapide et precis) mais lorsqu'il est confronte a des situations d'erreur, d'attente indefinie, d'incerti- 
tude. Le client d'un service Web, derriere le proxy, est un programme applicatif qui, s'il veut remplacer 
parfaitement l'utilisateur, doit etre capable d'une performance comparable lorsque les choses ne se 
deroulent pas comme attendu. Une strategie realiste serait de soigner autant que possible la capacite 
de prendre en compte les defaillances du service et du reseau de la part du client, mais aussi de rendre 
facile l'intervention « manuelle » de l'utilisateur dans les cas, que Ton espere rares, d'erreur et de 
defaillance que Ton ne sait pas traiter entierement par programme. L'utilisateur n'est plus un maillon 
de la chaine de traitements, qui est automatisee, mais agit plutot au niveau du parametrage, de la 
surveillance et de la reparation du processus. Par ailleurs, dans les cas de doublure d'un site Web, une 
interface homme/machine avec 1' application pour laquelle on a produit une interface de service Web 
existe deja... 

Les applications accessibles par navigateur Web sont une cible importante des technologies des services 
Web, mais elles ne represented pas la seule cible. Ces technologies ont pour ambition de s'attaquer 
aux processus et aux applications strategiques et, par agregation et dissemination, de creer la possibi- 
lite de nouvelles combinaisons, de nouveaux processus automatises, qui comprennent des dizaines, 
des centaines (voire plus) d' applications reparties, qui interagissent entre elles sans intervention 
humaine dans leur fonctionnement normal (qui inclut le controle et le traitement d'une dose de 
defaillances partielles). 

Les technologies de services Web peuvent prendre en charge le veritable systeme nerveux de l'activite 
de production, de circulation, d'echange et de consommation des biens et des services. Pour mettre 
en ceuvre des architectures en adequation avec ce projet, les technologies sur lesquelles reposent les 
services Web (SOAP/WSDL/UDDI) sont necessaires mais ne sont certainement pas suffisantes. 
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II est indispensable de construire, sur la couche de base, des technologies d' infrastructure qui pren- 
nent en charge au moins trois fonctions cles : 

• la fiabilite de Fechange ; 

• la gestion de la securite ; 

• la gestion des transactions. 

II faut rappeler qu'une technologie d' infrastructure, dans le cadre des services Web, est toujours batie 
selon la meme methode : par la specification d'un protocole, avec sa syntaxe (le format des messages 
echanges et des assertions qui sont integrees dans des documents, par exemple WSDL), et un ensemble 
de regies qui fixent F interpretation et le traitement de ces messages et assertions. La mise en ceuvre, 
par des implementations differentes, du protocole en conformite avec les specifications garantit en 
principe l'interoperabilite de ces implementations. 

La gestion de la fiabilite de Fechange (presentee chapitre 18) se trouve dans une situation paradoxale. 
Les technologies de services Web ont comme premiere cible la communication entre applications, 
garantie de l'interoperabilite : apres avoir defini un protocole d'echange (SOAP), un langage de 
description des interfaces (WSDL) et un service d'annuaire (UDDI), on aurait pu s'attendre a un 
effort immediat pour mettre, autant que possible, les applications communicantes a Fabri des 
defaillances du reseau et des participants a Fechange. II n'en est rien car deux autres sujets ont retenu 
pratiquement toute F attention de la communaute : la securite et les langages pour definir les scenarios 
des processus metier repartis. Les deux sujets sont certainement tres importants, mais le fait est que 
la gestion de Fechange fiable a ete etonnamment sous-estimee, voire considere comme accessoire. 
Nous pensons que la sous-estimation de cette fonction d'infrastructure est une des causes du faible 
taux d' adoption des services Web car elle joue un role fondamental. 

Lobjectif de la gestion de Fechange fiable est pourtant simple a enoncer : donner aux applications parti- 
cipantes a Fechange Fassurance qu'un message est transmis une et une seule fois dans la sequence 
d' emission, ou que si ce n'est pas le cas Femetteur a un compte rendu fiable de Fechec de la transmis- 
sion. II est evident que la programmation des applications qui dialoguent dans un tel contexte est facili- 
tee car elle ne doit pas prendre en compte les situations d'incertitude sur la transmission du message. 

La gestion de Fechange fiable (chapitre 18) est done traitee, par la force des choses, de facon un peu 
academique puisque aucune solution n'est reellement disponible. Nous presentons la technologie 
HTTPR d'origine IBM, qui a le merite d' avoir ete proposee tout au debut de Fessor des services Web, 
mais qui n'a pas encore depasse le stade de prototype. Lidee est de « fiabiliser » HTTP et done de 
rendre la gestion de la fiabilite transparente au niveau SOAP (le message SOAP ne sait pas s'il 
voyage sur un « canal » fiabilise ou non). 

La technologie HTTPR est une technologie elegante, mais qui reste marginale et destinee, selon 
Fintention meme des auteurs, a des usages specifiques. Ce n'est que depuis le debut de Fannee 2003 
que le sujet commence a recevoir Fattention qu'il merite, d'abord avec la proposition de specification 
WS-Reliability (9 Janvier 2003) par Sun Microsystems et d'autres partenaires. Nous presentons cette 
specification qui a comme objet la fiabilisation du message a sens unique SOAP par une extension 
standard du protocole. 

Le 13 mars 2003, IBM, BEA, Microsoft et TIBCO ont propose une nouvelle specification WS-Reliable- 

Messaging (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngbbspec/html/ws^ 
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accompagnee d'un livre blanc et d'une roadmap. Cette specification est parue trop tard pour que nous 
puissions la traiter dans cet ouvrage mais nous pouvons constater qu'avec l'engagement des deux 
acteurs historiques (IBM et Microsoft), la problematique de la fiabilite de l'echange a desormais 
trouve sa place dans 1' architecture des technologies des services Web. 

Le chapitre 19 presente 1' infrastructure de gestion de la securite. C'est sans doute le sujet d'infra- 
structure sur lequel les travaux de specification et d' implementation ont fait le plus de progres, sur la 
base il est vrai d'un travail preexistant assez avance. En fait, le W3C propose des technologies 
essentielles pour la gestion de la securite des services Web (XML Signature, XML Encryption) et 
l'OASIS propose SAML (Security Assertion Markup Language), framework d'echange d'informations 
(assertions) de securite au format XML qui peuvent etre encapsulees dans des messages SOAP. 

La gestion de la securite touche les exigences classiques d'authentification et d'autorisation des 
acteurs et agents logiciels impliques dans les echanges ainsi que la confidentialite, l'integrite et la 
non-repudiation de ces memes echanges. 

Le 27 juin 2002, Microsoft, IBM et VeriSign ont soumis les specifications WS-Security a la commu- 
naute OASIS. BEA, Cisco, Intel, Iona, Novell, RSA, SAP et Sun Microsystem ont immediatement 
manifeste leur disponibilite pour travailler dans le comite technique OASIS. La gestion de la securite 
est le seul des trois sujets d' infrastructure sur lequel les travaux de specification avancent sur une 
unique roadmap, avec la participation des acteurs les plus importants impliques dans le developpement 
des technologies des services Web. L'approche choisie integre des mecanismes patrimoniaux large- 
ment utilises comme les certificats X.509 et les tickets Kerberos. 

Le chapitre 20 presente 1' infrastructure de gestion des transactions. Sur ce sujet, deux specifications 
se cotoient : 

• BTP {Business Transaction Protocol), propose initialement par BEA avec d'autres partenaires (dont 
Oracle et Hewlett-Packard) et gere, depuis mars 2001 par un comite technique OASIS ; 

• le tandem WS-Coordination/WS -Trans action, (9 aout 2002), propose par IBM, Microsoft et BEA, 
qui n'a pas encore ete confie a un organisme de standardisation. 

BTP compte un certain nombre d' implementations disponibles. WS -Coordination etWS -Transaction 
sont plus recentes et, de plus, coordonnees avec BPEL4WS (Business Process Execution Language 
for Web Services), langage destine a specifier des scenarios de processus metier promu par les 
memes societes. La presence de BEA dans cette deuxieme initiative, ainsi que d'autres signes comme 
le fait que Collaxa, editeur d'une des premieres implementations de BTP et aujourd'hui auteur d'une 
des premieres implementations de WS-Coordination/WS -Trans action, ne prend plus en charge le 
moteur BTP dans la nouvelle version de son serveur d' applications suggerent que BTP n'est qu'une 
etape vers le standard de gestion des transactions pour les services Web, qui va se concretiser dans 
revolution de WS -Coordination et WS-Transaction. 

Le chapitre 21 effectue un tour d'horizon des nombreuses specifications qui traitent de la gestion des 
processus metier. Ce domaine est actuellement l'objet de nombreux bouleversements et plusieurs 
nouvelles specifications sont apparues dans les derniers mois. Celles-ci touchent aux aspects de 
description des interactions entre les services Web qui participent aux processus et de l'ordre tempo- 
rel de ces interactions, decrites en termes de messages et de traitements metier associes a remission 
ou a la reception de ces messages (orchestration). Ces specifications traitent en outre de la maniere de 
decrire 1' interface publique des processus metier implementes par les moteurs d' orchestration 
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(choregraphie). Le chapitre dresse un rapide panorama des acteurs importants dans ce domaine et des 
principales specifications en presence : BPEL4WS (mis en ceuvre, avec WS -Coordination et WS- 
Transaction sur la base du moteur Collaxa, dans une variante de l'etude de cas presentee chapitre 26), 
BPML,WSCIetWSCL. 

Les langages de definition de scenarios de processus metier, qui facilitent F orchestration de dizaines, 
voire de centaines (et meme plus) de services Web vont prendre de plus en plus d'importance en tant 
qu'outils de maitrise de la complexite des architectures reparties de demain. 

L'etude de cas 

L'etude de cas est le sujet de la cinquieme et derniere partie de l'ouvrage (chapitres 22, 23, 24, 25 
et 26). II s'agit de la mise en ceuvre d'une architecture orientee services sur la base des technologies 
de services Web, qui prend en charge un processus metier d' organisation de voyages (reservation de 
places d'avion, de chambres d'hotel, de voitures de location). 

L'ensemble du code source des scenarios d' architecture de l'etude de cas peuvent etre telecharges 
librement sur le site d'accompagnement du livre, a l'adresse http://www.editions-eyrolles.com. 

Nous avons choisi de simplifier au maximum, du point de vue fonctionnel, le processus, dont la 
complexite est vraiment tres inferieure a celle des veritables systemes de reservation centralises 
(GDS ou Global Distribution System) comme Amadeus, Sabre, Galileo, WorldSpan. L'avantage est 
que le contenu fonctionnel, a ce niveau de simplification, est comprehensible de facon intuitive par 
toute personne ayant eu une experience, meme minimale, de ce type de voyage et le lecteur peut done 
se concentrer sur l'objet de l'etude de cas, qui est l'architecture technique sous-jacente. Le contenu 
fonctionnel est presente chapitre 22. 

C'est un exemple Aggregation de services de reservation de places d'avion, de chambres d'hotel et 
de voitures de location, de la part d'un service d'une agence de voyages. II s'agit done d'une archi- 
tecture a trois niveaux : un systeme « client final » accede a un service d'une agence de voyages qui 
agrege les services de reservation dans le but de constituer une reservation de voyages globale. II est 
important de noter que 1' application repartie, dans la variante la plus simple, comporte en fait au 
minimum cinq agents logiciels actifs : 1' agent client (mis en ceuvre comme un client SOAP dans un 
navigateur Internet Explorer, presente chapitre 22), 1' agent serveur de 1' agence de voyages et un 
agent pour chaque systeme de reservation sectoriel (avion, hotel, voiture). 

Ce schema est decline d'abord dans une architecture completement statique, a savoir totalement 
configuree avant execution (chapitre 23). L'agregation de services est mise en ceuvre directement 
par le code applicatif Java du systeme de l'agence de voyages. Une telle approche est voisine de celle 
des architectures B2B, qui connectent de facon predeterminee une entreprise avec ses clients et ses 
partenaires. Les serveurs de cette premiere architecture sont tous implemented en Java par l'utilisation 
du toolkit Apache SOAP 2.3.1. 

Le chapitre 24 presente une architecture dynamique. L'idee est que d'une part les services de reser- 
vation sectoriels sont normalises par des organismes professionnels (fictifs) dans des documents 
WSDL standards et que, d' autre part, une pluralite de prestataires de ces services sont accessibles en 
ligne. Le port d'acces au service de chacun de ces prestataires est, lui aussi, determine a F execution. 

L'architecture dynamique fait done intervenir un annuaire de services UDDI, qui permet la decouverte 
dynamique des prestataires et de leurs ports d'acces. La mise en ceuvre du processus d' organisation 
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du voyage est done precedee par un processus de configuration dynamique de 1' architecture (choix 
des prestataires et de leurs ports d'acces). 

Le choix dynamique des prestataires, de leurs ports et a la limite des services est un point d' applica- 
tion privilegie de l'intelligence du service agregeant, e'est-a-dire de sa capacite de prise en charge 
des preferences du client et de mise en ceuvre de regies de gestion, qui peuvent devenir extremement 
sophistiquees (car elles represented Fexpertise metier de Fagence de voyages). On peut imaginer 
que les prestataires mettent en ceuvre le meme service minimal, decrit par le document WSDL stan- 
dardise par Forganisation interprofessionnelle. A ce service minimal, chaque prestataire peut ajouter 
des services annexes qui font sa valeur ajoutee. Le prestataire peut en outre se distinguer par le niveau 
de qualite de service sur lequel il s'engage. Nous n'avons pas pousse l'exemple aussi loin : le choix 
des prestataires et des points d'acces est fait au hasard (Fexpertise metier de Fagence de voyages 
n'est pas le sujet de Fouvrage) et il faut rappeler que les engagements de niveau de qualite de service 
ne font pas encore Fobjet d'un langage d'assertions normalise. La mise en ceuvre de la configuration 
dynamique de F architecture est, comme pour le processus metier d' organisation du voyage, le resultat 
de F execution d'un code applicatif Java integre dans le systeme de Fagence. 

Le chapitre 25 met en ceuvre exactement la meme architecture, mais avec comme variante la re-imple- 
mentation du service agregeant en technologie Microsoft .Net (C#). II s'agit d'un exercice interessant au 
moins a deux titres. D'abord, cela permet de verifier, que, dans certaines limites d'utilisation de la tech- 
nologie des services Web, Finteroperabilite est effective et la technologie d' implementation d'un 
service a partir de la formalisation de son contrat (le document WSDL) est interchangeable et, a la 
limite, banalisee. Ensuite, cela nous permet de comparer concretement deux implementations du meme 
service, de tous les points de vue. II reste entendu que le but de Fouvrage n'est pas de trancher entre 
J2EE et .Net, mais au contraire de montrer que finalement, avec les services Web et, peut etre, pour la 
premiere fois dans l'histoire de Finformatique, le choix de la technologie d' implementation, qui reste 
un choix important et doit etre pese avec soin, n'est plus structurant ni irreversible par rapport a la mise 
en ceuvre du service (il peut Fetre, evidemment, pour d'autres raisons, surtout organisationnelles). On 
peut noter en passant que les microarchitectures respectives du service en Java/J2EE et en C#/.Net sont 
vraiment tres proches et que le passage de Fune a F autre est concretement tres simple a effectuer. 

Le dernier chapitre (chapitre 26) reprend F architecture statique du chapitre 23 mais la revisite en 
integrant une gestion trans actionnelle du processus metier de reservation et Fusage d'un langage de 
definition de scenario (BPEL). Cette gestion est destinee a suppleer aux faiblesses de F architecture 
initiale qui ne s'appuie que sur des implementations des specifications de base des technologies des 
services Web. La nouvelle architecture fait appel a Fune des premieres implementations des specifi- 
cations BPEL4WS, WS -Coordination et WS-Transaction, materialisee par - le serveur BPEL Orches- 
tration Server de la societe Collaxa. Le fonctionnement de F architecture qui en resulte est en mode 
« document » et asynchrone : les applications participates s'echangent des documents et utilisent 
les interactions successives (par - polling ou par callback) pour recuperer les resultats des traitements 
declenches. Cette derniere variante est plus didactique que realiste (les quatre applications partici- 
pates doivent fonctionner sur des machines installees avec le meme moteur Collaxa pour beneficier 
des fonctionnalites de messagerie asynchrone, de coordination et de gestion de transactions), mais 
donne une tres bonne idee de Forientation adoptee ces six derniers mois par les principaux acteurs 
des technologies des services Web dans le domaine de F infrastructure de gestion des processus 
metier et des transactions. 
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La relation de service 

L' architecture orientee services (AOS) est le terme utilise pour designer un modele d' architecture 
pour F execution d' applications logicielles reparties. 

Ce modele d' architecture prend forme au cours de l'activite pluriannuelle de specification des archi- 
tectures de systemes repartis, developpee dans des contextes aussi varies que ceux de : 

• l'Open Group (Distributed Computing Environment ou DCE ) ; 

• F Object Management Group (Object Management Architecture/Common Object Request Broker 
Architecture ou OMA/CORBA) ; 

• l'editeur de logiciels Microsoft (Distributed Component Object Model ou DCOM ). 

Les deux derniers modeles (CORBA et DCOM) relevent de 1' architecture par composants logiciels 
repartis plutot que de l'architecture orientee services, et le terme « service » est generalement absent 
de leur terminologie (sauf, par exemple, dans CORBA ou Ton parle de services CORBA a propos de 
fonctions offertes par la plate-forme de middleware aux composants applicatifs). 

L'activite des composants est qualifiee incidemment d'activite de prestation de services pour les autres 
composants de l'architecture, mais le concept de composant logiciel est primaire (de « premiere 
classe ») alors que le concept de service est secondaire et dependant de celui de composant. 

Les preoccupations essentielles de ces modeles sont : 

• la standardisation du mecanisme d'invocation de traitements distants (DCE, CORBA, DCOM) ; 

• la transparence de la localisation des composants dans un systeme reparti (CORBA, DCOM). 

Des travaux plus recents, comme ceux realises autour de Jini (Sun Microsystems), Biztalk (Microsoft) et 
surtout e-Speak (Hewlett-Packard), premiere plate-forme orientee services batie sur les technologies 
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XML, ont permis 1' emergence du concept de service qui offre un degre d'independance par rapport 
ail concept de composant logiciel. 

Par ailleurs, F emergence des technologies de services Web consolide un modele d' architecture dans 
laquelle le concept de service joue le role primaire alors que le concept de composant logiciel (qui 
met en ceuvre le service) est reduit a un role dependant, banalise et interchangeable. En outre, le 
concept meme de middleware disparait de l'architecture : les applications reparties n'ont pas besoin 
d'un systeme de middleware reparti commun pour communiquer, mais seulement de mettre en ceuvre 
des protocoles et des technologies de communication interoperables sur Internet. 



Documents sur l'architecture orientee services 

Le terme anglais correspondant d'architecture orientee services est Service Oriented Architecture (SOA). Avec 
I'essor des services Web, ce terme apparait a nouveau dans la litterature. Voici une liste d'URL sur le sujet : 

- http://www.sun.com/jini ; 
-http://www-4.ibm.com/software/solutions/webservices/pdf/roadmap.pdf ; 

- http://www-1 06.ibm.com/developerworks/webservices/library/ws-arc1 ; 

- http://www-1 06.ibm.com/developerworks/webservices/library/ws-arc2 ; 

- http://www-1 06.ibm.com/developerworks/webservices/library/w-ovr ; 

- http://www.talkingblocks.com/resources.htm ; 

- http://msdn.microsoft.com/architecture ; 

- http://www.w3.org/TR/ws-arch. 



Les elements du service 

Une application logicielle qui exerce une activite dont les resultats sont directement ou indirectement 
exploitables par d'autres applications, eventuellement reparties sur un reseau, joue le role de presta- 
taire de services. L'ensemble des resultats exploitables de l'activite est appele prestation de services, 
et les applications qui en beneficient jouent le role de client du service. Les termes « prestataire » et 
« client » correspondent a des roles interpretes par les applications dans la relation de service. Une 
application peut etre en meme temps prestataire de plusieurs services distincts et cliente de differents 
services. 

Une prestation de services reside dans l'ensemble des resultats de l'activite de 1' application prestataire, 
qui peuvent etre classes en trois groupes (voir figure 2-1) : 

• Informations : V application prestataire effectue pour le compte du client des traitements dont les 
resultats sont communiques au client. Ce groupe comprend les applications a haute intensite de calcul 
(exemple : la mise en ceuvre de modeles d' analyse numerique) aussi bien que les applications qui 
effectuent des recherches et des agregations de donnees stockees sur des bases. 

• Etats : l'application prestataire gere les etats et les changements d'etat, representes par des ensembles 
de donnees (exemple : une base de donnees de gestion). Les etats peuvent etre volatiles, persistants 
(s'appuyant sur des donnees stockees sur memoire secondaire) et durables (non seulement persis- 
tants, mais aussi capables de survivre a des defaillances de l'application prestataire et de son 
infrastructure, y compris de sa memoire secondaire). Un changement d'etat est en principe 
toujours reversible, mais il faut que l'application soit concue et mise en ceuvre a cet effet. 
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• Effets de bord: l'application prestataire effectue des interactions avec l'environnement, c'est-a- 
dire avec un ensemble de dispositifs qui permettent V entree et la sortie de donnees du systeme 
(exemple : l'impression d'une facture). Les effets de bords sont, a Finverse des changements d'etat, 
irreversibles par definition. 

Un sous-ensemble important des effets de bord est constitue par les interactions directes entre le presta- 
taire et le client. Lesdites interactions constituent le support d'actes de communication (exemple : la 
requete contenant une selection multicritere suivie d'une reponse contenant les resultats). L' ensemble 
des actes de communication echanges entre le client et le prestataire est appele interface de service. 



-Service 




Informations 



Effets de bord 



Figure 2-1 

Les elements d'une prestation de service. 



Plusieurs exemples peuvent clarifier les concepts de service, prestataire et client : 

1. Un service d'archivage de fichiers gere un systeme de stockage de fichiers sur memoire secondaire. 
L'acte de communication utilise par un client pour demander l'archivage d'un fichier est une 
requete qui presente le fichier a archiver en piece jointe. Le prestataire du service, a partir de la 
reception de la requete, execute une tache qui produit comme resultats : le stockage du fichier 
dans la base d'archivage (changement d'etat), puis la production d'une reponse a l'intention du 
client, laquelle a comme contenu un identifiant unique dans la base d'archivage du fichier archive 
(information via un acte de communication). 

2. Un service d'interrogation de donnees marketing restitue de l'information marketing en reponse 
a des requetes de selection multicri teres. Le prestataire du service, a partir de la reception de la 
requete de la part du client, (« Combien de menageres de moins de cinquante ans dans le 
departement de la Somme ? ») execute la tache qui consiste a interpreter les criteres de la requete, 
rechercher et/ou calculer le paquet des donnees qui repondent aux criteres recus et emettre 
une reponse adressee au client qui a comme contenu ledit paquet (information via un acte de 
communication). 
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3. Un service de diffusion audio en continu gere la diffusion multicanal de musique numerique. 
L'acte de communication de la part du client du service consiste a envoyer le flux des donnees qui 
represente la musique a diffuser. Cet acte de communication ne demande pas de reponse. La tache 
du prestataire du service est la reception, la transformation du flux d' entree dans les formats 
prevus et la retransmission sur les canaux de diffusion (effet de bord). 

4. Un service de publication d' informations boursieres communique aux abonnes les valeurs d'un 
ensemble de titres, ainsi que des statistiques, a intervalles reguliers. Le client du service est a 
l'ecoute des actes de communication du prestataire du service, emis a intervalles reguliers, dont le 
contenu est ledit ensemble de valeurs. Le client du service ne donne pas d' accuse de reception. La 
tache du prestataire est de rassembler a chaque intervalle Fensemble des valeurs et d'accomplir 
ensuite Facte de communication a Fintention des clients abonnes. 

5. Un service de gestion de liste noire notifie en temps reel a une application les identifiants des 
usagers qui ne sont plus autorises a acceder a ladite application. La tache du prestataire est de 
reagir en temps reel a chaque evenement de passage en liste noire (qui lui est communique, par 
exemple, par un administrates systeme via une interface homme/machine), de notifier immedia- 
tement 1' information horodatee a l'application cliente et de recuperet - l'accuse de reception. Si 
1' application cliente ne restitue pas d' accuse de reception dans un laps de temps parametrable, le 
prestataire emet a nouveau la meme notification. 

Ces exemples mettent en valeur plusieurs caracteristiques du concept de service : 

• Les actes de communication sont utilises pour mettre en ceuvre le service (preparer les conditions 
de la prestation) ou bien font partie directement du deroulement de la prestation de services : 

- la prestation comprend en general l'echange d'actes de communication (exemples 1, 2, 3, 4, 5), 
des calculs (exemples 2 et 4), des changements d'etat de ressources (exemples 1, 5) et des effets 
de bord (exemples 1,3); 

- la prestation peut etre constitute seulement d'actes de communication (exemples 2, 4, 5), sans 
changement d'etat des ressources, ni effets de bord. 

• L initiative de l'echange des actes de communication peut venir soit du client soit du prestataire : 

- F initiative vient du client dans les exemples 1, 2, et 3 ; 

- F initiative vient du prestataire dans les exemples 4 et 5. 

• Les liens entre actes de communication, informations produites, etats et effets de bord sont de 
differents types : 

- La prestation reside dans la production d' informations, de changements d'etat, d'effets de bord 
declenches par la reception d'un acte de communication emis par le client (1, 2, 3) qui vehicule la 
requete de prestation (ce mode de fonctionnement est propre aux architectures dites client/ 
serve ur). 
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- La prestation reside dans un acte de communication issu du prestataire et declenche comme 
resultat d'un traitement effectue par F application prestataire, ce traitement pouvant etre declenche 
par un evenement approprie (4, 5). 

Les concepts de service, prestataire et client de F architecture orientee services sont done tres generaux, 
bien plus que les concepts de serveur et de client dans F architecture client/serveur traditionnelle 
(appelee aussi, de facon plus appropriee, architecture maitre/esclave) qui constitue une specialisation 
restrictive du modele de F architecture orientee services : 

• Le concept de serveur (esclave) est une specialisation du concept de prestataire de services. La 
prestation d'un serveur correspond a F execution d'une procedure (qui execute des calculs, des 
changements d'etat, des effets de bord) declenchee par un acte de communication (invocation de la 
procedure) de la pail du client (maitre). 

• Le seul type d'echange admis dans F architecture client/serveur est generalement l'appel de procedure 
distante (Remote Procedure Call ou RPC) dans le sens client-a-serveur. Cet echange, bidirec- 
tionnel synchrone, enchaine, suite a Finvocation de la pail du client (maitre), l'execution d'une proce- 
dure dans Fespace de travail du serveur (esclave), le retour du compte rendu de l'execution et, 
eventuellement, des informations produites par l'execution de la procedure. 

Parmi les exemples listes ci-dessus, seuls les exemples 1 et 2 se rapprochent du modele classique 
client/serveur. Les exemples 3, 4 et 5 sont considered plus proches du modele dit peer-to-peer. 

Les roles de client et de prestataire 

Une difficulte importante que Fon rencontre dans la maitrise du modele de F architecture orientee 
services est la comprehension de la nature des roles que sont ceux de client et de prestataire de services. 
En effet, ce modele s' applique, au-dela des architectures client/serveur, aux architectures reparties 
peer-to-peer, e'est-a-dire a des architectures reparties dans lesquelles il n'y a pas a priori de limitation 
de roles pour les applications constituantes. 

Une application qui fait partie d'une architecture orientee services peut etre impliquee dans plusieurs 
relations de services et interpreter en meme temps plusieurs roles de client et plusieurs roles de pres- 
tataire. Une architecture orientee services est done une federation de services (voir figure 2-2), a 
savoir une architecture d' applications reparties qui participent a un reseau d' 'echange de services. 

II est bien evident que Fechange de services peut etre circulaire : dans l'exemple de la figure 2-3, 
l'application Al joue en meme temps le role de client du service SA (exemple : un service d'achat en 
ligne) et le role de prestataire du service SB (exemple : un service de suivi de factures des achats 
effectues via le service SA) vis-a-vis de l'application A2, qui, a son tour, joue les roles symetriques. 

Nous appellerons par la suite une application qui a la capacite d'interpreter au moins le role de 
prestataire ou de client d'au moins une relation de service, une application orientee services. 
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Figure 2-2 

Une federation de services. 




prestataire 



SA : Service d'achat en ligne 



SB : Service de suivi de factures 



prestataire 



A2 



client 



Figure 2-3 

Echange circulaire de sendees. 
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Le contrat de service 

Le concept de service qui est vehicule par le modele de 1' architecture orientee services se veut inde- 
pendant de la mise en ceuvre des applications constituantes. Cette independance n'existe que s'il est 
possible de decrire (done definir et decouvrir) la relation de service independamment des implemen- 
tations des applications. 

La description d'une relation de service est formalisee par un contrat de service. Ce contrat decrit les 
engagements reciproques du prestataire et du client du service. Toute application pouvant satisfaire 
les engagements du prestataire (et, reciproquement toute application pouvant satisfaire les engage- 
ments du client) peut interpreter le role de prestataire (et, reciproquement, le role du client). 
Lorsqu'un contrat regente une relation de service, la realisation de la prestation de services reside 
dans F execution du contrat. 




Informations 



Figure 2-4 

Le contrat formalise la relation de service. 

Un contrat de service, dans le monde des relations professionnelles, est un document comportant 
plusieurs parties et dont les elements terminaux sont generalement appeles articles et clauses. Le 
contrat de service contient des articles et des clauses consacres a des sujets tels que : 

• F identification des parties contractantes ; 

• la description de la prestation objet du contrat ; 

• les modalites d' execution du contrat ; 

• les modalites d'interaction entre les parties. 

II est aussi courant que le contrat de service decrive les actions a entreprendre en cas de defaillance 
d'un des contractants ou d'impossibilite de realisation de la prestation. 
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Les elements du contrat 

Les elements du contrat de service sont organises en six themes majeurs : 

• 1' identification des parties ; 

• la description des fonctions du service ; 

• la description de 1' interface du service ; 

• la description de la qualite du service ; 

• la description du cycle de vie du service et du contrat ; 

• la description des termes de l'echange. 

L'arborescence de la figure 2-5 represente 1' ensemble des elements du contrat de service classes par 
themes. Un contrat de service contient, idealement, des articles et des clauses pour chacun des 
elements. 



Figure 2-5 
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Acteurs humains et agents logiciels 

Le contrat de service du modele de F architecture orientee services s' inspire directement du modele des 
contrats professionnels de service. II s'agit d'un document qui, par contenu ou reference, developpe 
l'ensemble des points permettant de decrire et done de definir la relation de service. 

Les elements du contrat sont « produits » et « consommes » par les acteurs humains et par les agents 
logiciels impliques dans les differentes phases des cycles de vie du contrat et de la prestation de 
service, dans les roles de clients, prestataires ainsi que dans des roles de tiers ou d'intermediaires. 

L'ensemble des acteurs humains et agents logiciels, impliques dans un contrat de service du cote 
client et du cote prestataire, est presente figure 2-6. Dans la suite de cet ouvrage, les termes « client » 
et « prestataire » (et aussi les termes « tiers » et « intermediaire ») seront souvent surcharges, a savoir 
utilises pour designer sans distinction les acteurs humains et/ou les agents logiciels impliques, le 
contexte permettant de lever l'ambiguite. 

Pour le contrat de service, le choix d'un format universel et extensible de structuration de documents 
comme XML s'impose, pour satisfaire les deux contraintes principales qui pesent sur le contrat de 
service : 

• Le contrat de service doit etre, en meme temps, lisible par des acteurs humains et exploitable 
(genere, interprets, agrege, decompose, indexe, memorise, etc.) par des agents logiciels. 

• Le contrat de service doit etre tout aussi facilement extensible, e'est-a-dire adaptable a Fevolution 
des services, des architectures et des technologies, et capable d'accueillir les nouveaux formalismes 
propres a de nouveaux types d'engagements. 
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Figure 2-6 

Producteurs et consommateurs du contrat. 
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Les structures de direction (management) respectives du client et du prestataire sont interessees par 
les aspects juridiques et financiers du contrat, tandis que les professionnels metier s'interessent plutot 
a la formalisation des aspects metier, et notamment a la semantique du service. 

Les differentes equipes de professionnels de I 'informatique (correspondants fonctionnels, concep- 
teurs, exploitants) ont la charge de l'essentiel du contrat de service qui, tel qu'il est defini dans cet 
ouvrage, porte une connotation fortement technique. 

Des parties du contrat de service peuvent etre produites et consommees par les agents logiciels impli- 
ques dans la mise en ceuvre au sens large du contrat de service. Les environnements de developpe- 
ment (outils d' edition, generateurs de code, compilateurs, etc.) mettent en ceuvre essentiellement 
deux fonctions : 

• la generation, a partir d'elements contractuels, de code garantissant la liaison, via l'interface de 
service, entre l'application cliente et l'application prestataire. Le code est integre dans l'application 
cliente (stub ou proxy) et l'application prestataire (skeleton). Le propre de l'approche AOS est que 
ces deux operations sont effectuees de facon totalement independante ; 

• la production d'elements contractuels et operationnels (l'interface de service et les elements 
techniques de liaison) a partir d'un code existant par retro-ingenierie. Cette technique permet 
notamment d'exposer comme un service tout ou partie des points d' entree et de l'activite d'une 
application existante. 

Les applications clientes peuvent consommer des elements contractuels en execution, notamment 
pour configurer dynamiquement la liaison avec des prestataires. Les applications clientes et prestataires 
peuvent aussi produire des elements contractuels a l'execution : certaines caracteristiques de la relation 
de service peuvent ne pas etre completement definies dans le contrat, mais peuvent faire l'objet de 
negotiation entre les deux applications lors de l'execution du contrat. Les infrastructures des applications 
impliquees dans la relation de service (les serveurs d' applications, par exemple) peuvent aussi exploiter 
le contrat de service pour un parametrage automatique de certaines caracteristiques operationnelles 
de l'execution. 

Les outils d' exploitation peuvent exercer une fonction de pilotage du service et de surveillance par 
rapport a la tenue des engagements de service, de la part du client comme du prestataire. 
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Identification des parties, description des fonctions 
et de P interface 

La figure 2-7 presente le detail de l'identification des parties, de la description des fonctions et de la 
description de l'interface. 
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Details du contrat de service. 
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Identification des parties 

Le contrat de service identifle les parties contractantes, c'est-a-dire les organisations et les individus qui 
agissent en tant que prestataires et clients du service objet du contrat. L' identification du prestataire 
est en general necessaire, alors que les clients peuvent rester anonymes. 



UDDI et ebXML 

UDDI (Universal Description, Discovery and Integration ; http://www.uddi.org), un consortium promu par IBM, 

Microsoft et Ariba, propose les specifications d'un service d'annuaire pour services Web. Aujourd'hui a la 

version 3, les specifications ont ete transferees en juillet 2002 a I'OASIS (juillet 2002) http://www.oasis-open.org) 

pour standardisation. 

Les specifications UDDI sont presentees dans les chapitres 11 et 12. 

OASIS ebXML (http://www.ebxml.org) propose le concept de CPP (Collaboration Protocol Profile) qui organise des 

informations propres aux participants d'un processus metier, ainsi que des informations d'interface, d'implementa- 

tion de I'interface et de qualite de service. 



Des relations de service simples n'impliquent qu'un client et qu'un prestataire. D'autres relations 
plus complexes demandent la presence d'autres applications dont les services annexes sont necessaires 
a la realisation de la prestation du service primaire objet du contrat. Un exemple de service annexe est 
le service d'authentification, qui est necessaire a la realisation d'une prestation securisee. 




Figure 2-8 

Relations entre client, prestataire, tiers et intermediate. 
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Le contrat de service mentionne l'organisation prestataire du service d'authentification, dont le client 
et le prestataire du service primaire sont clients. Ces applications jouent un role de tiers par rapport 
au client et au prestataire de la relation de service primaire objet du contrat. 

D'autres applications jouent le role d' intermediate entre le client et le prestataire. Les types de 
services d' intermediation sont tres diversifies, et certains sont « transparents » par rapport au 
contrat : il n'est done pas necessaire que les intermediaires en question soient designes dans le 
contrat. Dans le chapitre sur les architectures dynamiques, nous evoquerons quelques services 
d' intermediation remarquables. 

Dans une AOS, les tiers et les intermediaires ont toujours un role de prestataire de services vis-a-vis 
du client et du prestataire du service primaire. Le contrat du service fait reference aux contrats de 
service tiers et d' intermediation impliques dans la relation de service primaire (voir figure 2-8). 

Description des fonctions du service 
Quel modele de service ? 

La definition des fonctions du service est la definition de V objet du contrat (en termes de description 
de la semantique du service), e'est-a-dire ce que F application prestataire fait (en termes de restitution 
d' information, de gestion d'etats, de gestion des effets de bord, d'echange d'actes de communica- 
tion) et ce que les donnees qu'elle echange signifient. 

Nous allons presenter la definition des fonctions de service a travers un exemple : le « service de 
correction d'orthographe francaise ». 

La description des fonctions du service de correction d'orthographe est une description du comporte- 
ment du « correcteur d'orthographe » (terme raccourci pour designer le prestataire du service en 
question), du point de vue des clients de cette prestation. Cette description dans un contrat doit 
permettre de predire et d'expliquer efficacement le comportement du prestataire. II s'agit done d'un 
modele de son comportement. 



La moderation du comportement d'un systeme informatique peut etre effectuee a plusieurs niveaux : 

« La complexite des systemes d'ordinateurs est mieux maitrisee lorsque ces systemes sont organises a des 
niveaux differents. L'analyse de chaque niveau facilite la comprehension des fonctions du systeme. La progression 
du niveau le plus primitif vers les niveaux plus eleves est accomplie par la creation d'une serie d'abstractions. 
Chaque abstraction supprime des details non necessaires [...] » « [...] Chaque systeme, a chaque niveau, est 
caracterise par un ensemble de composants et par un ensemble de modes de combinaison de ces composants 
dans des structures. Le comportement du systeme est formellement decrit a partir du comportement des compo- 
sants et de leurs combinaisons [...] » « [...] Chaque niveau [...] est caracterise par un langage distinct pour repre- 
sentor le systeme (les composants, les modes de combinaison, les lois de comportement) ». (D.P Siewiorek, C.G. 
Bell, A. Newell, Computer Structures: Principles and Examples, McGraw-Hill, 1982 ; traduction de I'auteur). 



Quelle description du correcteur d'orthographe nous permet d'expliquer et de predire son comporte- 
ment ? Quel est le « langage » adapte pour representer le systeme au niveau du contrat de service ? 

Une reponse possible est la description du correcteur d'orthographe au niveau implementation, par 
une description technique de l'application logicielle qui le met en ceuvre {modele d' implementation). 
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Le modele d'implementation 

Le modele d'implementation est une description systemique. Le correcteur d'orthographe est modelise 
comme un systeme qui : 

1. recoit une chaine de caracteres en entree et la represente en memoire sous forme d'une structure 
de donnees ; 

2. soumet cette structure a un algorithme de comparaison a d'autres structures, lesquelles sont soit 
contenues dans une base de donnees chargee en memoire, soit generees a la volee ; 

3. lorsqu'il ne trouve pas une structure « egale », F algorithme cherche dans la base (et/ou genere) 
des structures « voisines » (selon un certain calcul de « voisinage ») ; 

4. restitue ces structures sous forme de chaines de caracteres. 

Une description de ce type, plus precise et plus detaillee par rapport a celle qui est esquissee rapidement 
precedemment (avec le detail des structures de donnees, des algorithmes, de l'architecture des 
programmes) nous permet d'expliquer et de predire efficacement le comportement du systeme. Elle 
constitue un modele d'implementation et est done exploitable par le concepteur du logiciel de correction 
d'orthographe. 

Le modele d'implementation du logiciel qui interprete le role du prestataire peut-il etre utilise en tant 
que description de ses fonctions dans le contrat de service ? En theorie, oui, car cette description peut 
etre suffisamment precise pour constituer un engagement contractuel. En pratique, la presence d'une 
telle description dans le contrat souleve des problemes d'exploitation : 

• pour les organisations contractantes, clientes et prestataires du service de correction d'orthographe ; 

• pour les concepteurs des applications clientes et prestataires ; 

• pour les applications clientes et prestataires en execution. 

Le contrat vu par les contractants 

Ce qui interesse les professionnels metier clients est le fait que Ton puisse soumettre a 1' application 
prestataire des mots de la langue francaise, auxquels 1' application prestataire applique les regies de 
l'orthographe francaise et renvoie une liste en reponse a ces soumissions ou en cas d'erreur, etc. 

Qui plus est, un systeme logiciel qui utilise des structures de donnees differentes, des algorithmes 
differents, un langage de programmation different, bref, qui met en ceuvre un modele d'implementation 
totalement different, pourrait parfaitement faire F affaire. 

II faut done une description precise, mais qui utilise le langage propre au probleme pose, a savoir 
l'orthographe de la langue francaise. Les professionnels metier clients ne sont pas, a priori, interesses 
par le modele d'implementation du systeme car ils n'ont pas a le mettre en ceuvre ni a le developper. 

Ce qui interesse les professionnels metier prestataires est le fait de pouvoir mettre en evidence les 
fonctions offertes par l'application qu'ils mettent en ceuvre et le niveau de qualite operationnelle du 
service propose. 
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En revanche, la publication du modele d' implementation peut : 

• d'un cote engendrer la violation d'un secret de fabrication (par exemple, des algorithmes particu- 
lierement efficaces) ; 

• et de l'autre poser un obstacle a tout changement du modele d'implementation, puisque Fapplication 
cliente pourrait baser sa propre implementation sur le modele du prestataire publie (qui devient, 
par le simple fait de la publication, un engagement du prestataire). 

Le contrat vu par les concepteurs des applications 

Le concepteur de Fapplication cliente du correcteur d'orthographe est interesse par : 

• la description identique a celle qui est destinee au contractant, qui lui permet de valider fonction- 
nellement F utilisation du service dans son programme client ; 

• les details techniques de Finterface entre Fapplication qu'il doit mettre en ceuvre et Fapplication 
prestataire (par exemple le fait que les mots du francais sont echanges sous forme de chaine de 
caracteres, avec un certain format d'encodage, etc.)- Ces informations techniques precises sur 
Finterface lui permettent de communiquer avec un systeme dont il ignore a priori Farchitecture et 
la technologie d'implementation. 

Si le concepteur de Fapplication cliente est interesse par F implementation du canal d'interaction, en 
revanche, il n'est pas interesse par F implementation de Fapplication prestataire. En conformite a un 
principe d'occultation (information hiding), il est preferable que le client ne connaisse pas cette 
implementation car il pourrait etre tente d'introduire dans son application, meme inconsciemment, 
des choix de mise en ceuvre dependants de F implementation d'une application prestataire specifique. 
Certes, cette connaissance offre un interet technique (par exemple, pour ameliorer les performances) 
et applicatif (par exemple, pour exploiter directement un comportement applicatif du prestataire), 
mais cette demarche introduit aussi un couplage fort avec le prestataire. Ce couplage pourrait par la 
suite empecher le remplacement du prestataire par un autre qui proposerait les memes fonctions et 
les memes interfaces mais une meilleure qualite de service (plus de fiabilite, de performance, de 
disponibilite. . .) via un modele d'implementation totalement different. 

Ce principe d'occultation vaut aussi pour le concepteur de Fapplication prestataire, au-dela de 
l'exigence du secret de fabrication, car la publication du modele d'implementation limite les modifi- 
cations du modele, puisqu'il expose son application a des utilisations qui s'appuient non seulement 
sur les fonctions du service, mais aussi sur la particularite de leur mise en ceuvre dans un modele 
d'implementation donne. 

Le contrat vu par les applications en execution 

A l'execution, Fapplication cliente peut utiliser les informations d'une description de service, 
exploitables par programme, a des fins diverses de decouverte, de recherche, de verification, etc. En 
supposant que Fapplication cliente soit capable de faire de la decouverte dynamique d' applications 
prestataires (par exemple pour trouver un service de correction d'orthographe), elle aura besoin, pour 
conduire ses recherches, d'une description fonctionnelle du service rendu ainsi que d'une specification 
d' interface d'interaction. 
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A V execution, F application prestataire peut, de facon symetrique, utiliser une description fonction- 
nelle, exploitable par programme, pour la communiquer (ou communiquer ses modifications) a des 
intermediaires et a des clients potentiels. 

Le modele fonctionnel 

La presence du modele d'implementation de l'application prestataire dans le contrat de service 
constitue un engagement contractuel qui renforce le degre de couplage de F architecture, aussi bien 
entre le contrat et la mise en ceuvre du prestataire, qu'entre l'application cliente et l'application 
prestataire. 

Pour rediger le contrat de service, nous avons besoin d'une description du correcteur d'orthographe a 
un niveau different de celui du modele d'implementation : le niveau fonctionnel. 

Le modele fonctionnel du correcteur d'orthographe est, comme le modele d'implementation, une 
description systemique. Le correcteur d'orthographe est decrit comme un systeme constitue par les 
composants suivants : 

• des objectifs : Fobjectif est de detecter les mots qui n'appartiennent pas au lexique francais et, si le 
cas se produit, de proposer des mots du lexique francais qui ressemblent aux mots detectes ; 

• des moyens d' interaction {actions) avec Fenvironnement : c'est-a-dire des actes de communication 
avec les clients, comme receptionner les mots a corriger et emettre la liste de mots de remplacement 
a proposer ; 

• des connaissances : c'est-a-dire des informations et des regies metier qui lui permettent d'accomplir 
efficacement sa tache : le lexique francais, les regies d'orthographe, un critere general de ressemblance 
entre une suite quelconque de caracteres et les mots du lexique francais, etc. 

Ces composants fonctionnels interagissent selon une regie generale de comportement dont la 
description concise est la suivante : le systeme utilise les informations et les regies en sa possession 
pour selectionner les actions lui permettant d'atteindre ses objectifs. 



Le principe de rationalite 

Un agent logiciel, et en general un systeme, peut etre decrit en termes d'objectifs, de moyens d'interactions, 
d'informations et de regies, organises selon le principe de rationalite (utiliser les informations et les regies pour 
selectionner les moyens appropries permettant d'atteindre les objectifs). Le systeme est done decrit comme un 
agent rationnel, dont le niveau d'intelligence depend de la « qualite » des informations et des regies en sa possession. 
Cette demarche a ete explicitement proposee par A. Newell, dans sa conference historique de 1980 a I'American 
Association of Artificial Intelligence (reproduite dans A. Newell, The knowledge level, Artificial Intelligence, 1 8, 1 982). 



Le modele fonctionnel permet d'expliquer le comportement d'un agent logiciel prestataire de services 
tout aussi bien que le modele d'implementation. L'application qui met en ceuvre le service de correc- 
tion d'orthographe, produit sa prestation parce qu'elle est equipee de moyens d' interaction, ^infor- 
mations et de regies, qu'elle utilise pour attendre ses objectifs. C'est, d'ailleurs, la description que 
nous avons tendance a donner lorsque nous essayons d'expliquer a un utilisateur n'ayant aucune 
competence informatique le comportement du correcteur d'orthographe integre dans son logiciel de 
traitement de texte. 



Le contrat de service 

Chapitre 2 



Les modeles fonctionnels, comme les modeles d' implementation, sont des descriptions systemiques, 
dans le sens qu'ils decrivent le coiTecteur d'orthographe comme un systeme dote d'une structure et 
d'un comportement qui realise une fonction. 

II existe une difference fondamentale entre les deux modeles : le modele d' implementation est 
construit a partir de structures de donnees, programmes, algorithmes, etc., c'est-a-dire a partir de la 
structure interne de 1' application en tant qu' agent logiciel. Le modele fonctionnel est construit, quant 
a lui, a partir du lexique francais, des regies d'orthographe, etc., c'est-a-dire des entites propres au 
monde de l'orthographe francaise sans aucune mention a la structure interne de l'application. 

II s'agit d'une difference de niveau de description : la premiere description se situe au niveau 
implementation et trouve sa place dans un document de conception du logiciel. La deuxieme description 
se situe au niveau fonctionnel et est contenue dans la section de definition des fonctions du contrat de 
service (voir figure 2-9). 



Contrat de service 

« Correction d'orthographe » 

Definition des fonctions 



Objectifs : 

Detection des mots n'appartenant pas au lexique frangais 

Proposition des mots du frangais ressemblant au mot a corriger 

Actions : 

Lire les mots a corriger 

Ecrire une liste (eventuellement vide) de mots... 

(voir « Definition des interfaces ») 

Informations et regies: 

Lexique frangais 
Regies d'orthographe 
Regies de grammaire 
Critere de voisinage des mots 



Figure 2-9 

Definition des fonctions du contrat de service « correction d'orthographe 



Un modele partiel 

II faut bien comprendre que la definition des fonctions du contrat de service n'est pas un modele 
fonctionnel complet de l'application prestataire, mais seulement de son role en tant que prestataire de 
service. L'incompletude touche la largeur et la profondeur du modele. 

D'abord, l'application qui joue le role de prestataire du service (de correction d'orthographe, par 
exemple) peut interpreter d'autres roles de prestataire pour d'autres services (comme la verification 
grammaticale, le dictionnaire des synonymes et des antonymes, etc.), chacun de ces services ay ant 
son propre modele fonctionnel, eventuellement correle aux autres. Lactivite de service reelle de 
l'application peut done etre plus large que celle decrite dans un contrat de service. 
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L'incompletude du modele fonctionnel du contrat peut aussi etre plus fondamentale : certains objectifs, 
certaines regies et informations, qui entrent en jeu lors de la prestation du service, peuvent constituer 
des secrets de fabrication de 1' application prestataire que Ton ne souhaite rendre publiques ni aux 
applications prestataires concurrentes ni aux applications clientes, surtout lorsqu'une relation 
commerciale est en jeu (par exemple, une agence de voyages qui offre un service de cotation de voyages 
en ligne peut ne pas souhaiter la publication de ses regies de calcul de cotation). Les regies en question, 
tout en faisant partie du modele fonctionnel de 1' application, ne font done pas partie du modele 
fonctionnel du service. 
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Figure 2-10 

Relation entre le modele fonctionnel du service et le comportement du prestataire. 



Boite noire 

En conclusion, nous pouvons rappeler la regie qui dicte que dans une AOS ou les relations de service 
qui lient les applications participantes sont regies par des contrats de service, les prestations objet des 
contrats doivent imperativement etre decrites au niveau fonctionnel, et qu'il est incorrect d'inclure les 
modeles d'implementation des applications prestataires dans les contrats de service. L' implementation 
de F application prestataire est done une boite noire par rapport au contrat de service, sauf pour ce qui 
touche 1' implementation de la communication. 



RDF et Web semantique 

L'activite Semantic Web du W3C (http://www.w3.org/2001/sw), parrainee directement par « I'inventeur du Web » et 
actuel directeur du W3C, Tim Berners-Lee, rassemble des chercheurs en intelligence artificielle avec des experts 
reseau et Internet et affronte la problematique de la description des ressources Web au niveau semantique par un 
formalisme exploitable par programme. Un produit de cette activite est le langage RDF (Resource Description 
Framework), formalisme XML utilisable pour representor des metadonnees sur les ressources Web. Les descrip- 
tions RDF des ressources Web sont exploitables par des logiciels intelligents, pour la recherche, la decouverte, la 
categorisation, I'echange, et I'exploitation desdites ressources. 

Le langage de description RDF est un langage de representation tres general. II a ete utilise au depart pour etre 
applique a des ressources de type document, et permet de publier effectivement des informations contractuelles 
comme I'auteur, la date de publication, le copyright, des informations de publication, etc. Des projets specialises, 
comme PRISM (Publishing Requirements for Industry Standard Metadata), developpent des specifications de 
metadonnees pour la description de documents propres a differents secteurs industriels. 
Dans le cadre du programme DAML (DARPA Agent Markup Language, http://www.daml.org/services), un groupe 
de travail a developpe une ontologie des services (a savoir une description formelle des termes utilises et des rela- 
tions entre ces termes) appelee DAML-S, qui va permettre de mettre en oeuvre des descriptions de services Web 
au niveau fonctionnel en utilisant RDF et les technologies Semantic Web. 
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Par ailleurs, nous avons evoque la possibilite que les fonctions publiees dans le contrat de service ne 
soient qu'une partie des fonctions mises en ceuvre par Fapplication prestataire. D'autres fonctions 
peuvent etre publiees dans d'autres contrats pour lesquels 1' application joue egalement le role de 
prestataire. Dans tous les cas, la description fonctionnelle complete de Fapplication, en termes 
d'objectifs, d'actions, d' informations et de regies, a savoir son cceur metier, constitue egalement une 
boite noire pour les clients et les autres prestataires de services. Plus precisement, certaines parties du 
modele fonctionnel sont publiees dans les contrats de service (avec differents niveaux de visibilite), 
alors que d'autres parties restent cachees aux clients et aux autres prestataires. 

Description de I'interface du service 

Bien que Ton puisse imaginer des cas dans lesquels le client et le prestataire du service ne communiquent 
pas directement, ou d'autres cas limites dans lesquels il n'y a pas besoin de communication directe, 
en general le client et le prestataire du service communiquent : 

• pour construire la liaison, instrumenter le contrat, se synchroniser, invoquer ou controler la prestation 
de services ; 

• parce que l'echange d'actes de communication fait partie integrante de la realisation de la prestation 
de service. 

La description de I'interface du service est done d'abord la description des actes de communication 
entre le client et le prestataire dans le cadre de la realisation de la prestation de services (interface 
abstraite). 

Une architecture orientee services se caracterise par le fait que les interfaces de service constituent 
les seuls moyens de communication entre agents participants : 

• Si la realisation d'une prestation de services demande une communication directe entre le client 
et le prestataire, cette communication doit obligatoirement s'effectuer via l'echange d'actes de 
communication definis dans I'interface du service. 

• Deux applications participates d'une AOS ne peuvent communiquer directement que dans le 
cadre d'une ou de plusieurs relations de service. 

La description de I'interface du service s'articule en deux parties : 

• la description de I'interface abstraite ; 

• la description de F implementation de I'interface (interface concrete et liaisons). 

Entre la description de I'interface abstraite et la description de F implementation de I'interface, il 
existe la meme difference de niveau que celle que Fon retrouve entre le modele fonctionnel et le 
modele d' implementation de Fapplication prestataire de services. 

Le modele d' implementation de Fapplication ne doit pas figurer dans le contrat de service, sauf pour ce 
qui touche F implementation de I'interface de service. Le modele d' implementation de I'interface doit 
obligatoirement figurer dans le contrat, car ce dernier doit fournir toutes les informations permettant la 
realisation de la prestation, notamment expliciter les technologies qui mettent en ceuvre la communica- 
tion entre le client et le prestataire. La mise en ceuvre d'une certaine implementation de I'interface de 
communication decrite dans le contrat constitue done un engagement de la part du prestataire qui 
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permet la realisation effective de F interaction avec les clients qui maitrisent cette implementation. 
L' implementation de F application prestataire de services se presente done au client comme une boite 
noire avec une interface transparente (voir figure 2-11). 



Client 



Prestataire 




Informations Effets de bord 

Figure 2-11 

Le prestataire est une boite noire avec une interface transparente. 

La designation des adresses de communication figure sur le contrat car elle constitue egalement un 
engagement qui permet la realisation effective du service. II n'est pas necessaire que les adresses 
figurent « en dur » dans le contrat de service, mais elles doivent etre reperables a partir du contrat, via 
un mecanisme ou des liens explicites (les adresses de communication peuvent etre decouvertes sur un 
annuaire en ligne, qui, lui, doit etre reperable a partir du contrat). 

L'interface abstraite 

L'interface abstraite est Fensemble des actes de communication entre le prestataire et le client du 
service, independamment des moyens mis en ceuvre pour accomplir physiquement ces actes. 

La description de l'interface abstraite comprend : 

• la syntaxe abstraite des actes de communication, qui est la description de la structure et des 
elements de Facte de communication ; 

• la semantique des actes de communication, qui est la description des actions accomplies au moyen 
des actes de communication par leur emetteur ; 

• la pragmatique des actes de communication, qui est la description des effets obtenus par F emission 
des actes sur le recepteur et sur Fenvironnement. 

Syntaxe abstraite 

La syntaxe abstraite d'un acte de communication est une description de sa structure abstraite, a savoir des 
elements qui composent Facte sans entrer dans une description precise (syntaxe concrete) des elements. 

Chaque type d'acte de communication est systematiquement caracterise par les elements suivants : 

• le (nom du) type de Facte ; 

• la description abstraite du contenu de Facte ; 

• la direction de Facte (client-a-prestataire ou prestataire-a-client). 
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La syntaxe abstraite fixe une partie des conditions de succes d'un acte de communication : un acte 
mal forme n'est pas accompli. 

Semantique 

La semantique d'un acte de communication est une description de Taction effectuee par l'emetteur 
de Facte au moyen de son accomplissement. Dans une AOS dont les applications constituantes 
entrent en communication seulement dans le cadre des relations de service, les actes de communica- 
tion qu'elles s'echangent ont un sens uniquement dans le cadre de ces relations de service : les actes 
de communication participent a la preparation, a F instrumentation, au controle, a la gestion et a la 
realisation des prestations de services. 

La semantique d'un acte de communication est done F association entre le type de Facte et Faction que 
l'emetteur accomplit. II faut bien comprendre que, meme s'il n'y a pas de relation evidente entre emet- 
teurs et clients ou entre recepteurs et prestataires, la semantique des actes de communication est 
toujours definie dans le cadre des fonctions du service rendu par le prestataire. Par exemple : si l'emet- 
teur est le client, Facte peut etre une requete d' execution d'une prestation de services ; si l'emetteur est 
le prestataire, Facte peut etre un accuse de reception couple a la promesse d'effectuer une certaine 
prestation, un compte rendu d' action, un rapport d'information a destination du client, etc. 

La semantique fixe la deuxieme partie des conditions de succes de Facte de communication, e'est-a-dire 
les conditions semantiques de succes, au-dela de la verification syntaxique que Facte soit bien forme. 

Les conditions semantiques de succes de Facte de communication sont remplies si : 

• l'emetteur a la capacite, le pouvoir, le droit et Fautorisation de produire et d'emettre Facte de 
communication ; 

• le recepteur a la capacite, le pouvoir, le droit, Fautorisation de receptionner, d' analyser et d'evaluer 
Facte de communication ainsi que d'accomplir ses effets pragmatiques (voir section suivante) ; 

• Facte est transmis dans un contexte et dans un environnement ou il est correct et pertinent. 

Pragmatique 

La pragmatique des actes de communication est, en general, la description des effets intentionnels sur 
le recepteur de Facte de communication, a savoir la modification de ses croyances (changements 
d'etat) et le declenchement d'actions (effets de bord) comme consequence de Facte. 

La pragmatique est done F association entre Facte de communication (emis par le client ou le prestataire) 
et les consequences de cet acte sur le recepteur (prestataire ou client) dans le cadre strict des fonctions 
du service (production d' informations, gestion d'etats, gestion des effets de bord, dont les actes de 
communication enchaines). Comme pour la semantique, il s'agit d'associer Facte avec ses conse- 
quences sur le recepteur en termes de preparation, d' instrumentation, de controle, de gestion et de 
realisation de la prestation de services. 

La pragmatique de Facte decrit done un ensemble d' engagements du recepteur (qu'il soit prestataire 
ou client) par rapport aux fonctions du service : pour le prestataire, les engagements sont en relation 
avec la realisation de la prestation de services, tandis que pour le client, elles sont en relation avec 
F utilisation correcte du service. 
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Dans le cadre d'un contrat de service, et contrairement a la semantique, la symetrie entre clients et 
prestataires n'est pas maintenue pour la pragmatique des actes de communication. 

En fait, les changements d'etat et les effets de bord cites doivent faire partie de la prestation de servi- 
ces, ou avoir une fonction instrumentale a l'accomplissement de la prestation de services. La conse- 
quence pratique est que la pragmatique des actes de communication est obligatoirement decrite dans 
le contrat de service lorsque le recepteur de Facte est le prestataire. Lorsque le recepteur est le client, 
la pragmatique de Facte est contractuellement decrite seulement lorsqu'elle constitue un engagement 
du client, necessaire au bon deroulement de la prestation de services. 

Pour reprendre l'exemple du correcteur d'orthographe, la pragmatique de l'acte de communication 
client-a-prestataire qui consiste a soumettre un mot pour verification d'orthographe doit etre decrite 
de facon precise. Un des elements de cette pragmatique est l'acte de communication de reponse que 
le correcteur emet a l'intention de son client, pour lui communiquer le resultat de ses investigations. 
Aucun effet pragmatique n'est decrit contractuellement pour cet acte de communication : l'applica- 
tion cliente n'a aucun engagement sur les consequences de sa reception (par exemple, F application 
cliente peut reposer la meme question cent fois - sauf ce qui peut etre explicitement stipule dans les 
clauses sur les limites de la prestation). 

Une partie de la pragmatique du client/recepteur peut etre explicitement formalisee dans les conver- 
sations et les processus metier (voir plus loin), lorsque certains changements d'etat et effets de bord 
produits par le client sont necessaires au bon deroulement de la prestation de services. Cependant, un 
service bien concu oblige le prestataire a prevoir des reactions appropriees dans le cas ou F effet prag- 
matique de son acte n'est pas mis en ceuvre par le client/recepteur (dissymetrie fondamentale de la 
relation de service). 

La pragmatique fixe les conditions de satisfaction de l'acte, c'est-a-dire les conditions qui permettent 
de tester si l'effet pragmatique (les changements d'etat et les effets de bord) d'un acte de communi- 
cation bien reussi (qui a rempli ses conditions de succes) s'est acheve correctement et completement. 

Une partie importante de la pragmatique decrit le traitement des situations d'erreur, et done les 
consequences des actes qui ne remplissent pas les conditions de succes ou de satisfaction. 

Mis a part les erreurs de transmission, qui concernent F infrastructure de communication, ces situa- 
tions d'erreur sont de plusieurs types : 

• l'acte est mal forme ou corrompu ; 

• l'acte est bien forme, mais son contenu est semantiquement defaillant ; 

• Femetteur n'a pas la capacite, le pouvoir, le droit ou Fautorisation d'emettre l'acte de communication, 
par ailleurs correct d'un point de vue syntaxique et semantique ; 

• le recepteur n'a pas la capacite, le droit, ni Fautorisation de receptionner l'acte et de produire son 
effet pragmatique ; 

• l'acte n'est pas correct ou pertinent dans le contexte et dans Fenvironnement ou il est transmis ; 

• l'acte de communication est correctement effectue (en ce qui concerne la syntaxe et la semantique) 
par un emetteur autorise et recevable par le recepteur ; le contexte de transmission est correct et 
pertinent ; l'acte remplit done toutes les conditions de succes ; l'effet pragmatique de l'acte 
(changements d'etat, effets de bord) ne s'est pas produit par defaillance du recepteur (l'acte ne 
remplit pas les conditions de satisfaction). 
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Le prestataire/recepteur d'un service bien concu couvre avec des reactions appropriees (par exemple : 
des messages d'erreur pertinents et detailles) la plus grande partie des situations d'erreur envisageables 
(non seulement les plus courantes). La prise en compte large et pertinente des situations d'erreur est 
un facteur essentiel pour la qualite du service. 



Les actes de langage ou de communication 

Le philosophe anglais J.L. Austin (J.L. Austin, How to do things with words, Oxford University Press, 1962) est 
considere comme le pere de la theorie des actes de langage (actes de discours, actes de communication), theorie 
reprise par le philosophe americain J.R. Searle (J.R. Searle, Speech Acts, Cambridge University Press, 1969). 
Cette theorie a eu une certaine influence en informatique (T. Winograd & F. Flores, Understanding Computers and 
Cognition, Ablex Publishing Corporation, 1986). 
Le philosophe J.R. Searle partage les actes de communication en cinq groupes : 

- assertifs : I'acte consiste a representor son contenu comme etant actuel ou vrai ; 

-engageants : I'acte reside dans I'engagement de I'emetteur d'accomplir Taction representee par le contenu de 
I'acte ; 

- directifs : le but de I'acte est que le recepteur accomplisse taction representee par le contenu de I'acte ; 

- declaratifs : I'accomplissement de I'acte coincide avec I'accomplissement de Taction representee par le contenu 
de I'acte ; 

- expressifs : I'accomplissement de I'acte est la manifestation d'un etat de I'emetteur de I'acte, represente par son 
contenu. 

Exemples : 

- un acte assertif est celui qui vehicule une information produite par le prestataire ; 

- un acte engageant est un accuse de reception de la part du prestataire d'une requete de la part du client ; 

- un acte directif est, par exemple, un appel de procedure distante ; 

- un acte declaratif est, par exemple, la livraison d'un certificat par une autorite de certification ; 

- un acte expressif est un message qui vehicule un etat d'erreur de I'emetteur. 

Plusieurs langages d'actes de communication entre agents logiciels distribues ont ete mis en ceuvre. 
Les plus importants sont : 

- KQML (Knowledge Query Manipulation Language), DARPA Knowledge Sharing Effort, http://www.cs.umbc.edu/ 
kqml/kqmlspec/spec.html ; 

-ACL (Agent Communication Language), Foundation for Intelligent Physical Agents (FIPA), http://www.fipa.org/ 

specs/fipa00037/PC00037E.html. 

La semantique et la pragmatique de I'interface de communication d'un service peuvent etre exprimees par la 

correspondance entre les operations WSDL et les processus DAML-S. Les specifications DAML-S decrivent en 

detail comment formuler cette correspondance. 
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Protocoles de conversation et processus metier abstraits 

Les echanges d'actes de communication peuvent etre formalises par la definition de protocoles de 
conversation. Un protocole de conversation est un echange contractuel d'actes de communication entre 
deux ou plusieurs agents et exprime done une partie de la pragmatique (les consequences attendues) 
des actes de communication. 

Le recepteur d'un acte de communication s'engage non seulement a effectuer certaines actions, 
toujours relatives aux fonctions du service, mais aussi a enchainer des la reception de l'acte de 
communication remission d'actes prevus par le protocole. 

Le protocole est represente par une machine a etats finis, chaque etat pouvant admettre un nombre 
fini d'actes de communication. Une conversation est done une correspondance (etat, acte)-a-etat. 
L' article du contrat sur la pragmatique precise les protocoles de conversation dans lesquels s'inserent 
les actes de communication de l'interface de service. Lorsque la prestation de services implique des 
protocoles de conversation, le prestataire et le client s'engagent a suivre ces protocoles, et le presta- 
taire s'engage a traiter les situations d'erreur (qui par ailleurs sont prevues dans une machine a etats 
bien concue). 

Les protocoles de conversation constituent une partie de la description des processus metier abstraits 
(publique). 

La description d'un processus metier abstrait est la description d'un enchainement : 

• d'actes de communication ; 

• de changements d'etat ; 

• d'effets de bord ; 

qui relevent d'une ou plusieurs prestations de services qu'un ou plusieurs prestataires de services 
pourvoient a un ou plusieurs clients. 

Le processus metier abstrait decrit done l'interaction entre deux ou plusieurs agents logiciels, inter- 
pretant les roles de prestataires et de clients d'un ou plusieurs services. II decrit de maniere explicite : 

• les regies et protocoles de communication, e'est-a-dire les interfaces et les protocoles de conversation 
entre agents dans leurs roles de clients et de prestataires des services impliques dans le deroulement 
du processus metier ; 

• les regies et protocoles de cooperation, qui constitue 1' ensemble coordonne de prestations (chan- 
gements d'etat et effets de bord) effectuees par les prestataires des differents services concourrant 
a la mise en ceuvre du processus et du resultat global ; 

• les regies et protocoles de coordination, a savoir l'enchainement des actes de communication, des 
changements d'etat et des effets de bord produits par chaque agent dans le deroulement du 
processus. 

Les descriptions des processus metier abstraits sont des elements contractuels references par les 
contrats des services dont les prestations sont impliquees dans le deroulement des processus eux- 
memes. Un processus metier abstrait peut impliquer plusieurs services, plusieurs clients et prestataires 
et done faire reference a plusieurs contrats. A l'inverse, un service peut etre implique dans plusieurs 
processus metier. 
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Traditionnellement, les langages de workflow ne font pas la difference entre description de la 
communication, cooperation et coordination entre applications reparties et enchainement de taches 
qui realisent Factivite de chacune des applications participantes. 

Dans le cadre des architectures orientees services, il convient de faire la distinction entre la description 
du processus abstrait (publique), que nous avons evoquee precedemment, et la description du processus 
executable (privee), qui decrit F enchainement des taches dans chaque application participant au 
processus abstrait. Le processus abstrait fait l'objet de references croisees avec les contrats de 
service, alors que les processus executables relevent plutot du modele d' implementation propre a 
chaque application participante et ne sont pas cites dans les contrats de service. 



Langages de definition de conversations et de processus metier 

Voici une liste de langages de specification de conversations et de processus metier qui ont ete developpes dans 
le cadre de la mouvance des technologies de services Web (ou technologies correlees) : 
-WSCL (Web Services Conversation Language 1.0, W3C Note 14 March 2002, http://www.w3.org/TR/wscl10) 
propose Hewlett-Packard a I'attention du W3C ; 

- BPSS (Business Process Modeling Specification Schema, http://www.ebxml.org/specs/ebBPSS.pdf}, promu par 
OASIS ebXML ; 

- BPML (Business Process Modeling Language, http://www.bpmi.org), qui est le resultat du travail de BPMI ou 
Business Process Modeling Initiaitive ; 

- WSCI (Web Services Choreography Interface, http://wwws.sun.com/software/xml/developers/wsci) est propose 
par BEA, Intalio, SAP, Sun Microsytems ; 

-BPEL4WS (Business Process Execution Language for Web Services, Version 1.0, 31 July 2002, http:// 

www.ibm.com/developerworks/library/ws-bpel), propose par IBM, Microsoft et BEA. 

Ces langages, les eventuels kits de developpement et moteurs d'execution sont presentes dans le chapitre 21 . 



Un exemple 

L'acte de communication archive-document permet d'interagir avec une application prestataire du 
service d'archivage de documents. 

• syntaxe abstraite/elements caracteristiques de Facte de communication : 

- type : archive-document ; 

- contenu : le document a archiver ; 

- direction : client-a-prestataire ; 

• semantique (action accomplie par Femetteur) : acte « directif » correspondant a une demande 
d'insertion du contenu de Facte (le document) dans le systeme d'archivage ; 

• pragmatique/effets sur le recepteur (le prestataire) de la reception de Facte : 

- production de Facte de communication : accuse-reception-demande-archivage de la part du 
prestataire (acte « assertif/engageant » : assertion de la reception de la demande archive-document, 
du document a archiver et promesse d'archivage du document de la part du prestataire) ; 
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- changement d'etat de la base d'archivage (l'archivage du document contenu de Facte construit 
un nouvel etat durable de la base d'archivage comprenant le document nouvellement archive) ; 

- production de l'acte de communication : informe-archivage-document-reussi de la part du 
prestataire (acte « assertif » : le document est archive). 

La description de la pragmatique de l'acte donne ci-dessus est simphnee et ne rend pas compte des 
situations d'erreur de l'acte et de ses effets, telles que : 

• erreurs de syntaxe : acte de communication mal forme, document corrompu, etc. ; 

• erreurs de semantique : Femetteur n'a pas le droit de formuler la demande, la taille du document est 
superieure au maximum consenti, etc. ; 

• erreurs de pragmatique : echec de Foperation d'archivage, etc. 

La description de Facte presente precedemment est abstraite a double titre : 

• La reference au modele fonctionnel du service (la sauvegarde dans la memoire d'archivage, la 
gestion du journal) est effectuee au niveau fonctionnel, done independante des technologies mises 
en ceuvre pour implementer les fonctions du service et notamment la fonction de stockage. 

• La description de l'acte de communication est independante des technologies qui prennent en charge 
son accomplissement effectif (le format des messages, le protocole d'echange, les techniques 
d'encodage de donnees, le protocole de transport, le medium, etc.). 



[.'implementation de I'interface 

La description de F implementation de I'interface comprend quatre parties : 

• I'interface concrete ; 

• les liaisons ; 

• les ports de reception ; 

• les chaines d'acheminement. 

Les actes de communication sont accomplis par le biais de la transmission de messages ayant des 
formats definis, transmission effectuee dans le cadre de differents styles d'echange specifies (inter- 
face concrete). Une interface abstraite peut etre implemented par plusieurs interfaces concretes 
(differents styles d'echange, differents formats des messages). 

Une interface concrete est mise en ceuvre sur une infrastructure de communication (liaison). L'infra- 
structure de communication est constituee d'une convention de codage du contenu du message et 
d'un protocole de transport. Une interface concrete peut etre mise en ceuvre via plusieurs infrastructures 
de communication (plusieurs conventions de codage, plusieurs protocoles de transport). 

Une infrastructure de communication permet de communiquer avec un ou plusieurs ports de reception 
des messages. 



Le contrat de service 

Chapitre 2 

Un message est emis par une application expedi trice et transmis sur 1' infrastructure de communication 
pour etre recu par une application destinataire. Entre ces deux agents, le message peut passer par 
plusieurs agents intermediaries qui forment une chaine d'acheminement. Chaque agent intermediate 
est recepteur du message emis par Fagent precedent, et emetteur du message pour l'agent suivant 
dans la chaine, l'expediteur etant le premier emetteur et le destinataire le dernier recepteur. 

L'interface concrete 

En general, a chaque acte de communication peut correspondre un ou plusieurs types de messages 
avec leur propre style d'echange et de format. 

Un message est une unite d' information transmise par une application expeditrice a une application 
destinataire dans le cadre de l'accomplissement d'un acte de communication. Pour etre analyse et 
compris, un message doit etre hautement structure et autosuffisant, a savoir contenir ou referencer 
toute information necessaire a son analyse, comprehension et interpretation. 

Lorsque le « nom » du type d'acte de communication est encode dans le contenu du message, Facte 
de communication est un acte performatif, c'est-a-dire un acte qui nomme explicitement dans son 
contenu Taction accomplie en l'effectuant. 



Actes performatifs 

La philosophie du langage definit comme acte performatif un acte de communication dans lequel est present un 
verbe performatif a la premiere personne du present : « je demande... », « j'ordonne... », « je promets... », qui 
nomme I'acte accompli (une demande, un ordre, une promesse). Le contenu du message qui vehicule I'acte 
contient, en plus, les arguments du performatif (I'objet de la demande, de I'ordre, de la promesse, etc.). 
Le message d'invocation du RPC met en oeuvre un acte performatif car le nom de I'acte est explicitement code 
dans le message (en suivant une certaine convention). La description de I'effet pragmatique d'un acte performatif 
peut etre classee sous son nom. D'autres modes de communication sont bases sur I'interpretation du contenu du 
message par des regies d'appariement. Dans ce cas, la classification des effets pragmatiques est plus complexe. 



Styles d'echange 

Du point de vue de 1' emetteur, la transmission d'un message consiste generalement a accomplir deux 
operations : 

• ouverture d'une connexion au port de reception du recepteur ; 

• envoi du message sur le port de reception en utilisant la connexion ouverte. 

Differents styles d'echange de messages sont mis en oeuvre dans les architectures reparties et sont 
adaptes a des usages differents. Les styles d'echange decrits plus bas forment une liste non exhaustive, 
mais representative des usages les plus courants. 
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Message a sens unique 

Le style basique d'echange de messages est le message a sens unique (unidirectionnel) : l'emetteur 
ouvre la connexion avec le port de reception, envoie le message sur le port et ferme la connexion. En 
fait, l'emetteur ne reste pas en attente, sur la connexion ouverte, d'un message du recepteur interpre- 
table comme reponse ou accuse de reception. Le message a sens unique est adapte a des applications 
comme la notification periodique d' informations. 

Requete/reponse 

La requete/reponse fait partie des styles d'echange les plus courants. L'expediteur ouvre une 
connexion au port de reception, envoie le message et reste en attente sur la connexion d'un message 
de reponse de la part du recepteur. A la reception de la reponse, la connexion est fermee. Le message 
de reponse peut se limiter a un accuse de reception, peut vehiculer le compte rendu d'un traitement, 
des informations resultat d'une interrogation, ou un message d'erreur. Attention : le protocole est 
synchrone du point de vue de la connexion (l'emetteur ne peut pas envoyer un autre message sur la 
connexion ouverte avant d' avoir recu la reponse), mais il n'est pas necessairement bloquant du point 
de vue de la ligne d' execution {thread) de l'emetteur, qui n'est pas oblige de suspendre son execution 
en attendant la reponse. 

Uappel synchrone de procedure distante (RPC synchrone) est un cas particulier de requete/reponse. 
L'appel correspond a l'invocation d'une procedure (pour les langages « par objets » a l'invocation 
d'une methode sur un objet distant) avec ses arguments, et la reponse correspond au compte rendu de 
l'invocation avec eventuellement des donnees resultat. 

Sequence de messages (streaming) 

L'emetteur ouvre une connexion avec le port de reception, envoie plusieurs messages en sequence sur 
le port de reception du destinataire. A la fin de la sequence, il envoie un message special qui, par 
convention, signifie la fin de la sequence et ferme la connexion. Ce style est utilise pour diffuser de 
1' information en continu (a contenu visuel ou audio, par exemple), parfois a plusieurs destinataires en 
meme temps (broadcasting). 

Requete/reponse multiple 

La requete/reponse multiple est une combinaison des styles requete/reponse et sequence de messa- 
ges. L'emetteur ouvre une connexion sur le port de reception, envoie un message et reste en attente 
sur la connexion d'une sequence de messages de reponse dont le dernier element est un message 
special signifiant par convention la fin de la sequence. 

Format du message 

Le format des messages decrit la syntaxe detaillee (concrete) des types de message mettant en ceuvre 
les actes de communication. La structure du message propre au protocole d'echange SOAP 1.1 est 
presentee figure 2-12. 

La distinction en-tete/corps dans la structure du message sert a distinguer la partie fonctionnelle (le 
corps), qui represente le contenu de Facte de communication, de la partie operationnelle (l'en-tete), 
qui vehicule des informations destinees a 1' infrastructure de traitement des messages (figure 2-13). 
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Format du message SOAP 1.1. 
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Figure 2-13 

Une enveloppe SOAP qui vehicule la representation SOAP d'un RPC. 
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La liaison 

Codage des contenus 

Les applications orientees services sont mises en ceuvre par des programmes implementes a Faide de 
differents langages de programmation. Le contenu des messages echanges est fabrique avant remission 
du message par une transformation des structures de donnees du programme et a la reception par la 
transformation inverse. 

La presence d'une convention de codage facilite la construction/interpretation du message. Une 
convention de codage du contenu des messages definit : 

• un systeme pivot de types de donnees simples et complexes, independant des langages de 
programmation ; 

• une convention pour coder les donnees de ces types dans les messages (codage de valeurs des types 
de base, serialisation de structures de donnees en arborescence ou en graphe, codage physique de la 
chaine de bits, etc.). 

II est necessaire par la suite de mettre en ceuvre pour chaque langage de programmation la correspondance 
entre le systeme de types pivot et le systeme de types du langage. Cela permet de faciliter la production 
et la consommation du message en sauvegardant le principe d'occultation reciproque des informations 
d' implementation des applications participant a Fechange. 

Pour obtenir la meme facilite de production et de consommation de messages sans systeme de types 
pivot, il faudrait definir la correspondance des types pour chaque couple de langages de programmation 
(soit N(N-l)/2 correspondances a la place de N) ; cette approche imposerait en outre que Femetteur 
connaisse le langage de programmation du recepteur, en violation du principe d'occultation de 
1' implementation des participants a l'echange. 

Protocoles de transport 

Les messages sont transmis de l'emetteur au recepteur au moyen d'un protocole de transport des 
trames sur le reseau qui relie les applications. Le meme type de message peut etre transmis au moyen de 
plusieurs protocoles de transport differents. Le contrat de service fixe le ou les protocoles de transport 
utilises pour chaque type de message. 
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Figure 2-14 

Une requite HTTP qui transporte I'invocation d'un RPC SOAP. 
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Messages et technologies de services Web 

Les technologies de services Web s'attaquent particulierement a la definition du format de message, des conventions 

d'encodage et des protocoles de transport. 

SOAP specifie I'utilisation de documents XML comme messages. La specification SOAP (SOAP 1.1) etablit : 

- une grammaire pour definir le format et la structure de messages (en termes de documents XML) ; 

- une convention qui doit traiter les differentes parties du message et si le traitement est obligatoire ou optionnel ; 

- une representation codee pour vehiculer des donnees atomiques et des structures de donnees propres a 
plusieurs langages de programmation dans les messages (style de codage) ; 

- un ensemble de consignes (liaison) pour transporter les messages sur le protocole de transport HTTP ; 

- une representation de la requete et de la reponse d'un appel de procedure distante (RPC) ; 

- un ensemble de consignes supplementaires pour transporter des messages avec des documents heterogenes 
en pieces jointes. 

La presentation de la specification SOAP 1.1 fait I'objet des chapitres 7, 8 et 9. 

Les protocoles Internet et, notamment, HTTP sont rappeles chapitre 5. 

Le systeme de types pivot qui aujourd'hui s'impose (il a ete adopte par SOAP) est le systeme XML Datatypes, 

defini dans la norme XML Schema. Un rappel de la norme XML Schema est effectue au chapitre 6. 

Le langage WSDL (WSDL 1.1) permet de specifier non seulement I'interface abstraite, mais aussi le format de 

message, les conventions de codage et les protocoles de transport. Les elements de definition de ('implementation 

de I'interface sont contenus dans I'element binding (liaison). 



Designation des ports de reception 

La designation des adresses des ports de reception du prestataire fait partie du contrat de service. 
Bien evidemment, a la place de la designation de ces adresses « en dur » dans le contrat, celui-ci peut 
se limiter a enoncer le mecanisme d'indirection qui permet de decouvrir ces adresses au moment de 
la realisation de la prestation (par exemple, le contrat peut designer un annuaire accessible qui publie 
les adresses de communication, au lieu de designer les adresses elles-memes). 

Lorsque les echanges sont a F initiative exclusive du client, comme dans les architectures client/ 
serveur traditionnelles, le contrat de service doit designer le ou les points d'acces du prestataire, mais 
il est inutile et done redondant de designer le point d'acces du client. A l'inverse, si tout ou partie des 
actes de communication definis sont a 1' initiative du prestataire, il faut que l'adresse du client soit 
designee dans le contrat, ou reperable a partir du contrat, au meme titre que celle du prestataire, ou 
bien communiquee a F execution. 



Ports et technologies de services Web 

Le langage WSDL 1.1 permet de specifier les adresses de communication via les elements port. Chaque port 
etablit une association entre une liaison (et done, implicitement une interface) et une seule adresse de communication, 
toujours sous format URI. 

Les ports de communication des services peuvent etre indiques directement dans un annuaire UDDI, avec la 
reference au document WSDL decrivant I'interface de service du port. 
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Chaines d'acheminement (routing) 

Les architectures reparties, qui mettent en ceuvre des applications reellement exploitables, implementent 
des chaines d'acheminement complexes. Les messages sont achemines de l'expediteur au destinataire 
en passant par une chaine d'intermediaires qui jouent des roles de prestataires de services secondaires : 
de securite, de non-repudiation, d' audit, etc. 

Les informations necessaires a Facheminement des messages de la pail des intermediaires sont 
normalement contenues dans I'en-tete, le coips du message etant destine au destinataire. 

Le concept d'intermediaire dans une chaine d'acheminement est en fait une specialisation du concept 
d'intermediaire entre clients et prestataires d'un service, dont la fonction est a la base de la mise en 
ceuvre d'une architecture dynamique de services (voir le chapitre suivant). 

La chaine d'acheminement, dont les principes sont detailles dans le contrat, peut etre une chaine 
totalement dynamique (le chemin du message est construit dynamiquement pendant la transmission 
du message). 
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Figure 2-15 

Une chaine d'acheminement. 



Chaines d'acheminement et technologies de services Web 

La specification SOAP prevoit le passage d'un message dans une chaine d'acheminement d'intermediaires entre 
l'expediteur et le destinataire. Le contenu du corps SOAP ne peut etre consomme que par le destinataire, alors que 
les contenus de I'en-tete SOAP sont destines a etre consommes par les intermediaires dans la chaine d'achemi- 
nement. 

OASIS ebXML Message Service Specification Version 2.0 specifie des directives d'acheminement des messages 
dans une chaine d'intermediaires sous formes d'elements et d'attributs a inclure dans I'en-tete d'un message 
SOAP. 

WS-Routing http://msdn.microsoft.com/ws/2001/10/Routing est une specification de directives d'acheminement 
(statiques et dynamiques) a integrer dans un en-tete SOAP propose par Microsoft. Elle est completee par WS- 
Referral, qui permet de gerer des tables d'acheminement. 



Nous avons presente dans ce chapitre les principes de l'architecture orientee services et le concept de 
contrat de service. Nous avons aussi decrit les articles du contrat qui touchent l'identification des 
parties ainsi que la description des fonctions et de 1' interface du service. Dans le prochain chapitre, 
nous allons completer la description des articles du contrat (la qualite de service, la gestion du cycle 
du service et la formalisation de l'echange) et nous allons etablir un etat de lieux general des techno- 
logies de services Web, en relation avec la mise en ceuvre d' architectures orientees services. 
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La qualite de service 



Le contrat de service ne se limite pas a la description des fonctions et interfaces de services ni a 
1' identification des parties impliquees. D'autres elements, tels que la description de la qualite de 
service, de la gestion du cycle de vie et des termes de Fechange, viennent completer le document. 

La figure 3-1 presente la liste detaillee des elements de description de la qualite de service, de la 
gestion du cycle de vie ainsi que des termes de l'echange. 

Le present chapitre decrit ces elements contractuels et esquisse la relation entre le modele de 1' archi- 
tecture orientee services, qui repose sur la notion de contrat, et les technologies de services Web. 

La qualite de service 

La qualite de service est un ensemble de proprietes operationnelles du service que Ton doit constater 
dans la realisation de la prestation. Formalisees dans le contrat, ces proprietes represented un ensemble 
d' exigences concernant la mise en ceuvre du service et constituent done un engagement de niveau de 
service (Service Level Agreement ou SLA). Ces proprietes peuvent etre reparties en six groupes : 

1. Leperimetre de la prestation : les proprietes rattachees precisent des informations complementaires 
par rapport aux fonctions du service, comme l'indication sur le caractere optionnel de certaines 
prestations, les exclusions explicites, la conformite aux normes et aux standards techniques et 
metier ainsi que les limites d' exploitation de la prestation de la part du client, notamment celles 
de sa capacite a pourvoir les resultats de la prestation a des tiers. 

2. La qualite de fonctionnement : e'est un ensemble de proprietes operationnelles qui caracterisent 
la realisation des fonctions du service. 

3. La securite : l'ensemble des exigences de securite sur la prestation de service. 

4. La robustesse : l'ensemble de proprietes qui caracterisent la capacite de resistance aux defaillances 
de la pail du prestataire ainsi que sa capacite de prise en compte des defaillances lorsqu'elles se 
verifient. 
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Figure 3-1 

Details du contrat de service. 
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5. La gestion du service : la disponibilite des fonctions et des interfaces generiques et/ou 
specifiques de gestion explicite du cycle de vie, de pilotage, de monitorage et de suivi de la prestation 
de service. 

6. La gestion du changement : les fonctions et les protocoles, eventuellement automatises, de gestion 
de changement (gestion de dysfonctionnements, des evolutions, de mise a disposition de nouvelles 
versions du logiciel prestataire). 

La qualite de service est une partie essentielle du contrat de service et du modele de F architecture 
orientee services. Nous avons vu que, en conformite aux principes d'independance du contrat de 
1' implementation et d'occultation de cette derniere, il est interdit d'inclure le modele d'implementa- 
tion du prestataire dans le contrat de service, sauf pour le modele d' implementation de l'interface. En 
revanche, les specifications des contraintes techniques sur l'accomplissement de la prestation ont une 
place tres importante dans le contrat. Elles specifient les caracteristiques operationnelles du compor- 
tement attendu du prestataire en termes de proprietes techniques « abstraites », a savoir des proprietes 
techniques de la prestation de services qui peuvent etre enoncees et comprises sans connaissance du 
modele d' implementation specifique de F application prestataire du service. 

Certains parametres de la qualite de service peuvent etre egalement negocies entre le client et le 
prestataire au moment de F instrumentation de la relation de service en execution. Dans ce cas, le 
contrat, au lieu d'etablir des valeurs explicites pour ces parametres, les declare negociables et indique 
le protocole de negociation a suivre pour determiner les valeurs a F instrumentation de la relation de 
service (un exemple de protocole de negociation est presente dans le chapitre suivant). 

La qualite de service est : 

• un terrain de competition entre prestataires qui offrent des services exhibant le meme modele 
fonctionnel et la meme interface ; 

• Fobjet d'observation et de suivi de la prestation de la part des clients et de tiers, ainsi que de notation 
des prestataires par des tiers independants jouant le role d'organismes devaluation et de notation. 



Technologies de services Web et qualite de service 

Hormis pour ce qui a trait a la securite et a la gestion de transactions (et qui est tres important par ailleurs), les 
technologies de services Web ne proposent pas encore de formalisme pour publier dans le contrat de service 
les engagements de qualite de service exploitables par les utilisateurs (developpeurs, exploitants, etc.) et par les 
applications (parametrage dynamique des delais d'attente, par exemple). 

IBM a evoque dans des travaux desormais dates ( Web Services Flow Language ou WSFL, Version 1.0) le develop- 
pement a venir de WSEL (Web Services Endpoint Language), langage qui devrait permettre de preciser certaines 
caracteristiques du prestataire (Endpoint) et notamment certains engagements de qualite de service rendu. A la 
date de redaction de cet ouvrage, il n'y a pas de resultats publies de ces travaux. 

Des elements de qualite de service, portant sur la securite et la fiabilite de I'echange peuvent etre inscrits dans les 
CPP (Collaborative Protocol Profile) des participants a I'echange, faire Fobjet d'une negociation et d'un accord 
consigne dans le CPA (Collaboration Protocol Agreement). Les CPP et CPA sont specifies par OASIS ebXML 
(ebXML Collaboration Protocol Profile and Agreement Specification, Version 1.0). 
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Perimetre de la prestation 

Limites de la prestation 

La partie du contrat sur le perimetre de la prestation precise les limites de la prestation qui ne sont pas 
clairement etablies par le modele fonctionnel du service. II s'agit de preciser le caractere optionnel de 
certaines fonctions (par exemple, les types de documents sur lesquels un service de recherche plein 
texte opere), de preciser explicitement les exclusions (la redondance sur les exclusions par rapport au 
modele fonctionnel apporte parfois de la clarte supplemental). 

Droits et obligations du client 

Un article important est dedie aux droits et aux obligations du client de la prestation. Nous pouvons 
imaginer un service qui met a disposition de ses clients directs des objets (comme des photos ou des 
images), a titre onereux, mais qui interdit a ces memes clients certaines exploitations de ces objets, 
comme la cession, le transfert, la location, la mise a disposition, la communication a des tiers, ainsi 
que la cession des droits. A F inverse, si le service opere sous un regime de libre service (par derivation 
de « logiciel libre »), le contrat pourra interdire aux clients F exploitation commerciale de ces memes 
objets ou obligera ses clients operant comme des prestataires a les mettre a disposition de leurs 
propres clients dans les memes conditions de libre service (par reference a la licence logiciel libre 
GPL et a ses variantes). Cette liasse de droits et obligations est typiquement correlee aux conditions 
commerciales d' exploitation du service (voir plus loin la section « Termes de Fechange »). II est 
facile de pre voir que F emergence d'une economie de services numeriques facilitera le developpement et 
la multiplication de formes contractuelles et commerciales adaptees. 

Conformite aux normes et aux standards 

La conformite aux normes et aux standards techniques et metier fait partie du contrat de service. Les techno- 
logies de services Web, specifiees par des organismes techniques de normalisation et de standardisation, 
sont typiquement des normes et standards techniques. Pour les technologies de services Web, les trois 
organismes les plus importants sont W3C, WS-I et OASIS ; ils seront presented plus loin dans ce chapitre. 

Les normes et standards metier sont generalement dictes par des organismes de standardisation et des 
organisations professionnelles des differents secteurs de Factivite economique et professionnelle. 

Un point extremement important est la gestion des versions et la configuration de ces normes et standards 
qui sont par definition evolutifs. Au-dela de la gestion des versions pour chaque norme et/ou stan- 
dard, la gestion correcte et precise des configurations de liasses coherentes et interoperables de 
normes et de standards, devient, du fait que chacun a son niveau de version, un defi crucial pour assurer 
concretement Finteroperabilite des applications orientees services. 



Gestion des versions et profiles 

Les technologies de services Web utilisent les vocabularies XML (XML Namespaces) pour declarer et faire reference 
aux normes et standards (et a leurs versions). 

WS-I, un consortium dont le but est de verifier et de valider I'interoperabilite des normes, des standards et des imple- 
mentations des technologies de services Web, a adopte comme methode de travail la definition des profils (profile), a 
savoir des liasses de technologies de services Web, chacune a un certain niveau de version, et de verifier et valider 
I'interoperabilite de chaque profit Le profil de base 1 .0 (Basic Profile 1.0) comprend SOAP 1.1, WSDL 1.1, UDDI 2.0. 
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Qualite de fonctionnement 



La qualite de fonctionnement touche des caracteristiques techniques operationnelles de la prestation 
de services lorsqu'elle est « en service », qui sont le dimensionnement, l'exactitude et la precision, la 
performance et l'accessibilite. 

Dimensionnement 

Le dimensionnement est un ensemble de caracteristiques chiffrees des fonctions du service. II s'agit 
notamment de deux types d' informations quantitatives : 

• les mesures de type nombre d'objets manipules (par exemple : le nombre maximal de documents 
archives par client d'un service d'archivage ou le nombre maximal de requetes par seconde) ; 

• les mesures de type taille d'objets manipules (par exemple : taille maximale du fichier a archiver, 
piece jointe du message de demande d'archivage). 

En general, les caracteristiques chiffrees formalisees dans le contrat sont des valeurs de frontiere, 
comme les valeurs maximales et/ou minimales, la taille maximale et/ou minimale, qui represented 
les limites de la prestation. 

La formalisation des caracteristiques chiffrees des fonctions du service permet a l'application cliente 
d'eviter, autant que possible, de decouvrir et d'etre confrontee aux limites de la prestation a F execution, 
sous forme d'une situation d'echec ou d'erreur dans la realisation du service. 

Exactitude et precision 

L'exactitude et la precision de la prestation de services sont aussi des caracteristiques chiffrees du 
systeme directement liees au modele fonctionnel. Elles sont pertinentes par rapport a certains services 
de type « informationnel » : 

• l'exactitude est une mesure de la deviation de la valeur vehiculee par le prestataire par rapport a la 
valeur theorique exacte (erreur standard) ; 

• la precision est la mesure de la « finesse » de la valeur (exemple : nombre de chiffres decimaux, 
frequence de mise a jour d'une valeur, etc.). 

Performance 

La performance touche deux types de mesures : 

• les mesures de delai : (par exemple : temps de reponse d'une requete) valeurs minimales, moyennes, 
maximales, variances et autres mesures statistiques ; 

• les mesures de debit : (par exemple : nombre de requetes traitees par unite de temps) valeurs 
minimales, moyennes, maximales, variances et autres mesures statistiques. 

Les engagements de performance (valeurs statistiques) sont differents des engagements de dimension- 
nement (valeurs absolues). La tenue des engagements sur des valeurs statistiques de performance doit 
etre validee par des services annexes de monitorage et de suivi. 



L'architecture orientee services 

Premiere Partie 

La formalisation des engagements de performance dans le contrat a une autre consequence pratique : 
F application cliente peut utiliser ces engagements pour parametrer de facon realiste ses delais d'attente 
maximaux (timeout). 

Accessibility 

L'accessibilite est une propriete qui represente la capacite d'une application prestataire de services a 
realiser effectivement la prestation quand elle est « en service ». L'accessibilite est en fait definie 
comme la probabilite d'obtenir avec succes la prestation a un instant T. 

Attention, il ne s'agit pas d'une mesure de disponibilite du prestataire : lorsque le prestataire est 
indisponible, il est evidemment inaccessible, mais l'accessibilite se mesure relativement aux situations 
de disponibilite. A un instant donne, une application prestataire peut etre disponible mais inaccessible, 
typiquement a cause d'une attaque de DOS (Denial of Service), dans lequel 1' application prestataire 
de services est submergee d'appels. A l'origine de l'attaque, il peut y avoir soit un client agissant par 
malveillance, erreur ou contamination, en violation aux engagements du contrat (qui peut prevoir, par 
exemple, un debit maximal de requetes emises par un client), soit un « intrus » qui usurpe l'identite 
d'un client. 

L'accessibilite est liee a la gestion des priorites. Le contrat peut etablir explicitement des niveaux de 
priorite, avec des debits et des delais garantis pour chaque niveau. 

Le contrat peut contenir egalement des engagements d'accessibilite au service lorsque le prestataire 
est « en surcharge » : il s'agit soit de privilegier toujours les clients a priorite elevee, soit d'eviter de 
situations de famine pour les clients a basse priorite en dediant par exemple un canal de traitement 
qui garantit que des requetes non prioritaires seront malgre tout traitees dans un delai raisonnable 
me me en situation de surcharge. 

L'accessibilite est generalement garantie par des techniques de reconfiguration a l'execution du 
prestataire de services comme X equilibrate de charge et de la montee en charge dynamique (l'enga- 
gement et la capacite de mobiliser dynamiquement des nouvelles ressources de la part du prestataire 
au-dela d'un certain delai de reponse). 



Securite 



Le contrat de service formalise les exigences de securite de la prestation de services. Dans une 
architecture orientee services, les differentes fonctions de securite sont mises en ceuvre par F adoption 
de protocoles et de technologies standards. Le volet securite des technologies de services Web est 
traite dans le chapitre 19 de cet ouvrage. Nous rappelons ici les fonctions majeures de securite qui 
peuvent etre formalisees dans un contrat de service, eventuellement par une simple reference 
auxdits protocoles et technologies standards : authentification, autorisation, confidentialite, integrite et 
non-repudiation. 

Authentification 

L authentification fait reference a la capacite d' etablir la confiance en l'identite des agents logiciels et 
des acteurs humains participants a la realisation d'une prestation de services. L authentification est 
generalement reciproque : le client doit pouvoir authentifier le prestataire et, reciproquement, le 
prestataire doit pouvoir authentifier le client. 
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Plus generalement, lorsque plusieurs applications sont impliquees dans une prestation de services, 
l'authentification peut etre requise pour chacun des agents vis-a-vis des autres. Les techniques 
d'authentification utilisees dans les architectures distribuees d'aujourd'hui sont basees sur un certain 
nombre de standards, de protocoles et de technologies (architectures a cles publiques, certificats, etc.) 
qui sont connues et maitrisees et dont F usage est en voie de normalisation pour les technologies de 
services Web. 

L' article Authentification du contrat precise les regies et les protocoles d'authentification des parties 
(acteurs humains et des agents logiciels) impliquees comme prestataires, clients, tiers et intermediaires 
dans la relation de service. 

Autorisation 

L'acces a un service est generalement filtre par des autorisations, attributes au client dument identifie 
et authentifie sur la base de ses droits. Le controle d'acces peut regarder les fonctions du service, les 
actes de communication et les adresses de communication (ports de reception). 

La notion de liste de controle d'acces (Access Control List) est centrale. Une liste de controle d'acces 
est une liste de paires (identifiant, droits). Pour chaque client, designe par son identifiant, une liste de 
droits donne les prestations de services, les actes de communication, les adresses de communication 
auxquelles il a le droit d'acceder. Lorsque Faeces est demande, une autorisation est generalement 
donnee sur la base des droits, en sachant qu'elle peut etre niee en execution meme en presence du droit 
correspondant, et cela pour des raisons contextuelles (exemple : gestion d'une liste noire dynamique). 

Un degre ulterieur de souplesse dans la gestion des droits d'acces et des autorisations peut etre introduit 
avec la notion de profil ou de groupe. La liste de controle d'acces peut etre constitute de couples 
(profil, droits). Un client peut presenter un ou plusieurs profils, et la liasse des droits du client est 
done calculee comme la fermeture transitive des relations (client, profils) et (profil, droits). 

Confidentialite 

La confidentialite touche generalement deux sujets : 

• Les echanges de messages : il s'agit de la protection, vis-a-vis d'observateurs externes non autorises, 
du contenu de Fechange et, a la limite, de son existence. 

• Le contenu des messages, de facon differenciee et independamment de Fechange. L'exemple classique 
est celui d'un service postal qui assure une prestation de non-repudiation (envoi recommande) et done 
interprete un role d' intermediate entre une application expeditiice et une application destinataire du 
message. Le service postal n'a pas le droit lire le contenu du message : le message est done encrypte et 
seul le destinataire possede la cle de dechiffrement. En revanche, le service postal est responsable de 
F identification et authentification du destinataire. 

La gestion de la confidentialite du message est plus complexe dans les architectures orientees services, 
puisqu'un message peut transiter par un nombre important d' intermediaires (chaine d'acheminement) 
avant d'atteindre le destinataire. Dans ce cadre, les differentes parties du contenu du message ne 
peuvent etre decryptees que par les differentes applications (jouant les roles d' intermediaires et le 
role de destinataire) auxquelles ces parties sont adressees. 

II ne faut pas oublier que, dans certains cas, F existence meme de la relation de service entre deux 
applications peut etre consideree comme confidentielle. 
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Integrite 

L'integrite du message et de son contenu peut etre protegee des agents indelicats, des erreurs de 
transmission ou de contamination. Les moyens permettant de valider l'integrite du message reposent 
sur les mecanismes d'authentification et de signature, qui permettent de detecter toute tentative de 
corruption. 

II est important de noter F inversion de la charge de la preuve sur la signature electronique par rapport 
a son homologue papier. En general, si une signature electronique est verifiee et identifie le posses- 
seur de la cle privee qui a ete utilisee pour creer la signature, c'est au possesseur de cette cle de prouver 
que la signature n'est pas la sienne, car Ton considere qu'il est impossible de signer sans connaissance 
du secret. 

Non-repudiation 

Une exigence importante, lorsque les echanges ont une valeur contractuelle, est la non-repudiation 
des actes de communication : non seulement l'emetteur et les recepteurs d'un message sont identifies 
et authentifies, mais remission et la reception du message sont tracees et ne peuvent pas etre niees 
par la suite. 

De facon generale, la non-repudiation est l'apport de la preuve d'un certain nombre d'evenements, 
comme l'approbation du message de la pail d'un acteur pourvu de l'autorite necessaire, ainsi que 
remission, la soumission au mecanisme de transport, le transport, la reception et la prise en compte 
du message. 

Les mecanismes de non -repudiation reposent sur des mecanismes de signature, et done sur 1' inversion 
de la charge de la preuve. 

La non-repudiation est generalement obtenue par l'utilisation d' intermediates dans l'echange de 
messages. Ces intermediates offrent differents services, notamment l'horodatage, la gestion du journal 
et l'acheminement des messages echanges. 

Services de securite 

La securite en general et chaque fonction particuliere (authentification, autorisation, confidentialite, 
integrite et non-repudiation) font intervenir, dans une architecture orientee services, au-dela de la 
relation de base client/prestataire, d'autres acteurs et agents logiciels qui jouent des roles divers de 
tiers (tiers de confiance, autorite de certification, agent d' intermediation, etc.) vis-a-vis du couple 
client/prestataire. La mise en ceuvre de proprietes de securite du service complexifie done une archi- 
tecture orientee services, tout en garantissant ses proprietes fondamentales, car lesdits tiers inter- 
preted les roles de prestataires de services de securite vis-a-vis des applications jouant les roles de 
prestataires et de clients du service primaire a securiser. 



WS-Security 

La securite est un sujet tres important et en plein developpement dans le contexte des technologies de services 
Web. II est presente chapitre 19. 

Une architecture generale de securite, qui comprend aussi une road map, a ete proposee par IBM, Microsoft et 
VeriSign. La premiere brique de l'architecture, premiere etape de la road map : Web Services Security (WS-Security) 
Version 1.0 , a ete publiee le 5 avril 2002. 
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Le 27 juin 2002, Microsoft, IBM et VeriSign ont soumis les specifications WS-Security a la communaute OASIS. 
BEA, Cisco, Intel, lona, Novell, RSA, SAP et Sun Microsystem ont immediatement manifeste leur disponibilite a 
travailler dans le comite technique OASIS (http://www.oasis-open.org/committees/wss). 
Le W3C propose des technologies essentielles pour la gestion de la securite des services Web : 

- XML Signature (http://www.w3.org/Signature) ; 
-XML Encryption (http://www.w3.org/Encryption/2001) ; 

- XKMS- XML Key Management (http://www.w3.org/2001/XKMS). 

XML Signature specifie le format et les regies de traitement des signatures XML. Les signatures XML permettent 
de faire beneficier les echanges bases sur le format XML des proprietes d'authentification des parties, de controle 
d'integrite des messages et de non-repudiation des echanges. La signature est organisee dans un element 
signature, qui contient des informations sur les donnees signees, la valeur de la signature et la cle de chiffre- 
ment. 

XML Encryption est une specification de gestion du chiffrement selectif (de tout ou partie) d'un document XML (un 
element, des donnees caracteres). Les donnees chiffrees sont-elles aussi presentees sous format XML. C'est 
done un outil destine a garantir la confidentialite des informations vehiculees par un document XML non seulement 
dans la phase de transport (fonction assuree par SSL ou TSL) mais aussi lorsqu'elles sont gerees et stockees par 
les applications. 

XKMS est une technologie basee sur I'infrastructure a cle publique. C'est un protocole d'interaction avec un tiers 
de confiance sur les operations de gestion de securite comme la gestion des cles, des certificats, des signatures, 
du chiffrement. La specification est organisee en deux parties : 

- X-KISS (XML Key Information Service Specification) permet de deleguer a un tiers de confiance les operations 
associees a une cle publique (decodage d'une signature , etc.) ; 

- X-KRSS (XML Key Registration Service Specification) permet d'interagir avec un tiers de confiance pour la 
gestion des cles. 

OASIS SAML (Security Assertion Markup Language) est un framework d'echange d'informations (assertions, 
requetes, reponses), de securite (authentifications, autorisations), base sur un langage d'assertions en format 
XML. Les assertions peuvent etre encapsulees dans des messages SOAP. SOAP est egalement utilise pour vehi- 
culer les requetes et les reponses aux « autorites » SAML, tiers de confiance qui emettent les assertions SAML 
(http://www. oasis-open, org/committees/security) . 

OASIS ebXML propose par ailleurs dans ses specifications du service de messagerie (ebXML Message Service 
Specification Version 2.0) des mecanismes de gestion de I'authentification des parties et d'integrite du message. II 
utilise les specifications W3C XML Signature. 



Robustesse 

La robustesse, ou resistance aux defaillances, est l'ensemble de proprietes operationnelles du service 
qui definissent : 

• d'un cote, les taux d' exposition aux defaillances (fiabilite, disponibilite) du prestataire ; 

• d'un autre cote, les proprietes du comportement du prestataire face aux defaillances et a la 
concurrence d'acces aux ressources (gestion de la continuity, gestion des transactions). 

Tandis que les articles du contrat sur la qualite du fonctionnement formalisent les proprietes opera- 
tionnelles de la prestation « en service », les articles sur la robustesse formalisent la problematique 
globale du « hors service », avec 1' exception notable de la gestion des transactions, laquelle est une 
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fonction globale qui traite aussi bien certaines proprietes du fonctionnement de la prestation que des 
proprietes de robustesse. 

Le but est non seulement de s'engager sur une limitation dans le temps et dans l'espace des situations 
hors service, mais egalement de garantir la minimisation de la portee temporelle et spatiale des 
consequences dommageables des situations hors service qui vont inevitablement se produire. 

Fiabilite 

La fiabilite est une propriete operationnelle du service qui touche trois sujets differents : 

• la fiabilite des echanges ; 

• la fiabilite fonctionnelle du service ; 

• la fiabilite des serveurs. 

Fiabilite des echanges 

Nous avons vu que la communication entre applications orientees services est mise en ceuvre par 
Yechange de messages. Un message est emis par une application expeditrice et transmis sur une 
infrastructure d'echange pour etre recu par une application destinataire. 

La transmission d'un message d'un emetteur a un recepteur s'articule en deux operations : 

• l'ouverture d'une connexion sur un port de reception ; 

• l'envoi du message sur le port de reception ; 

et done peut echouer pour deux raisons principales : 

• la defaillance de la connexion ; 

• la defaillance du point d'acces (port de reception). 

En outre, la transmission du message peut etre rendue incertaine pour deux raisons : 

• les delais de transmission peuvent engendrer des temps de latence impredictibles ; 

• l'ordre de reception des messages en sequence peut etre different de l'ordre d'emission. 

La fiabilite de la transmission est la probabilite de transmission d'un message dans son integrite, 
eventuellement dans la sequence d'emission, eventuellement sans repetition (exactement une fois). 
Un protocole de transport peut assurer un certain niveau de fiabilite de la transmission. 

La solution generate au probleme de fiabilite de la transmission est la constitution de files persistantes 
de messages, V accuse de reception et la relance de remission sur echec suppose de la transmission. 
La gestion de la file des messages permet la relance de remission, tandis que la persistance de la file 
sur memoire secondaire est a la base de la capacite de relance de remission de la part de 1' emetteur 
apres arret et reprise. A cause de l'incertitude des delais de transmission, l'emetteur peut considerer 
qu'un message emis n'est pas parvenu au recepteur alors que e'est le cas : l'envoi multiple est done 
possible et le recepteur doit etre en mesure de gerer la reception de plusieurs copies du meme 
message. 

Une solution a ce probleme est V idempotence des messages, a savoir la garantie que la reception de 
plusieurs copies du meme message a le meme effet que la reception d'une seule copie. 
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L'idempotence des messages est traitee a un niveau different de celui de Fidempotence des actes de 
communication. Au niveau fonctionnel, un acte de communication est idempotent si son effet prag- 
matique est le meme qu'il soit effectue une ou plusieurs fois dans un certain contexte spatial et 
temporel. Au niveau implementation, le message qui vehicule un acte de communication idempotent 
peut ne pas etre idempotent. Concretement, l'idempotence du message ne mettra jamais a l'epreuve 
l'idempotence de Facte de communication, car, par definition d'idempotence du message, la repetition 
de la transmission du message (au niveau echange) donne lieu a un seul acte de communication (au 
niveau fonctionnel). C'est justement lorsque Facte de communication n'est pas idempotent qu'il y a 
interet a traiter l'idempotence au niveau message pour assurer que Facte ne soit recu qu'une fois. 

L'identifiant de chaque message appartenant a une sequence de messages doit etre un ordinal. Le 
recepteur doit non seulement se rendre compte de trous dans la sequence de reception mais aussi 
reconnaitre des messages hors sequence, si ce n'est que pour leur consacrer un traitement particulier, 
voire les ignorer. Par exemple, en reception d'une sequence de messages audio, le recepteur doit : 

• s'accommoder de la qualite de la sequence avec trous qu'il a recue ; 

• ne pas « jouer » un message eventuellement recu hors sequence. 
Une infrastructure d'echange est dite totalement fiable si elle garantit : 

• la livraison des messages au recepteur exactement une fois dans le respect strict de Fordre d'emission ; 

• ou bien un compte rendu fiable de Fechec de livraison pour l'emetteur. 

L'obtention d'un niveau de fiabilite totale engage Femetteur aussi bien que le recepteur du message. 
L'emetteur doit etre capable de relancer Femission du message jusqu'a la certitude de reception ou a 
F expiration du delai maximal de relance. II doit egalement garantir que cette capacite puisse survivre 
aux defaillances qui provoquent F interruption de son fonctionnement. 

Le recepteur s'engage a traiter le message qu'il a recu et a faire en sorte que cette capacite a traiter le 
message survive aux defaillances (toutes ou partie) qui provoquent 1' interruption de son fonctionnement. 

Une infrastructure de communication totalement fiable met en ceuvre une gestion transactionnelle de 
files de messages persistantes en emission (chez l'emetteur) et en reception (chez le recepteur), ainsi 
que des processus independants de transfert entre les deux files d'attente. 

Certaines applications necessitent la fiabilite totale de transmission, tandis que d'autres tolerent des 
niveaux moindres de fiabilite. L infrastructure d'echange peut se limiter a garantir la livraison du 

message : 

• au plus une fois (par exemple, pour des messages non idempotents et non critiques) ; 

• au moins une fois (pour des messages idempotents et critiques) ; 

• sans garantie de coherence avec Fordre d'emission. 

La fiabilite des echanges est un sujet d' infrastructure, mais le niveau applicatif n'est pas a Fabri des 
consequences des defaillances et du caractere impredictible des temps de latence de la transmission. 
Moins le niveau de fiabilite de F infrastructure est eleve, plus le traitement des defaillances et du 
temps de latence doit etre pris en charge au niveau applicatif. 
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Technologies de services Web et echange f iable 

La gestion de la fiabilite des echanges pour les services Web est traitee chapitre 18. 
Les auteurs de cet ouvrage estiment que les efforts mis sur le sujet par la communaute des technologies de services 
Web n'est pas a la hauteur des enjeux qui sont aussi importants que ceux ayant trait a la securite. Plusieurs four- 
nisseurs de technologies de services Web (IBM, Microsoft) disposent de composants techniques eprouves, qu'ils 
proposent comme solutions proprietaires par definition non interoperables. Mais I'interoperabilite est cruciale sur 
ce sujet et ne peut etre obtenue que par la normalisation d'un protocole d'echange standard qui met en ceuvre la 
coordination necessaire a la realisation d'un echange fiable, independant des implementations des interlocuteurs. 
OASIS ebXML propose un protocole d'echange fiable comme fonctionnalite additionnelle dans sa specification 
d'un service de messagerie base sur SOAP 1 .1 (OASIS ebXML Message Service Specification, Version 2.0). Les 
parametres de qualite de service de I'echange fiable comme le nombre maximal d'essai de transmission, le delai 
maximal d'attente d'accuse de reception, etc. sont consignee dans le CPP (Collaborative Protocol Profile) des 
participants a I'echange fiable et peuvent faire I'objet d'une negotiation et d'un accord consigne dans le CPA 
(Collaboration Protocol Agreement). 

IBM a propose une specification de fiabilisation du protocole HTTP V1 .1 : A. Banks et al., HTTPR Specification - 
Draft Proposal, Version 1.0, 13th July 2001 (http://www-106.ibm.com/developerworks/webservices/library/ws-phtt/ 
httprspecV2.pdf), comme protocole de transport pour SOAP. Avec une fiabilisation au niveau du protocole de trans- 
port, la programmation applicative se simplifie car le traitement et la reprise des situations d'erreur sont effectues 
directement au niveau transport. 

Les fournisseurs de technologies d'echanges fiables specialises ou proprietaires (JMS ou Java Messaging 
System, IBM MQSeries, Microsoft MSMQ) proposent la mise en ceuvre de SOAP 1.1 sur ces technologies utilisees 
comme protocoles de transport. 

La situation d'impasse se debloque en debut 2003. Le 9 Janvier un groupement forme par Fujitsu Limited, Oracle 
Corp., Sonic Software Corp., Hitachi Ltd., NEC Corp. et Sun Microsystems propose la specification WS-Reliability 
{http://www.sonicsoftware.com/docs/ws_reliability.pdf). Le 13 mars, IBM, BEA, Microsoft et TIBCO proposent une 
nouvelle specification, concurrente de WS-Reliability : WS-ReliableMessaging (http://msdn.microsoft.com/library/ 
default.asp?url=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp). Nous pouvons desormais considerer 
que la gestion de I'echange fiable fait maintenant partie des sujets abordes par les specifications des technologies 
de services Web. 



Fiabilite fonctionnelle 

La fiabilite fonctionnelle est une caracteristique operationnelle du service directement liee a la definition 
de ses fonctions. Elle est une mesure de la conformite entre 1' implementation des fonctions du 
service de la part du prestataire et leur definition dans le contrat. 

La fiabilite fonctionnelle peut etre definie comme la probabilite d'execution fonctionnellement 
correcte d'une prestation de services. Elle se mesure statistiquement en nombre de prestations fonc- 
tionnellement correctes par rapport au nombre de prestations totales dans un laps de temps donne 
(complement du nombre d' anomalies fonctionnelles revelees dans le meme laps de temps). 

La fiabilite fonctionnelle est en relation etroite avec le niveau de test et de qualification de F application 
prestataire du service. Une application prestataire largement utilisee et operationnelle depuis long- 
temps presente sans doute un niveau de fiabilite fonctionnelle superieur a celui d'une autre application 
n' ayant pas la meme maturite. 
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Si le contrat de service inclut F article sur les services secondaires de gestion des dysfonctionnements 
(voir la section Gestion du changement), F application cliente peut, par exemple, signaler en ligne et 
en temps reel des defaillances fonctionnelles dont elle se rend compte. L'administrateur peut alors 
consulter en ligne la liste des dysfonctionnements deceles et non encore corriges. Cette liste est 
publiee et mise a jour par le prestataire avec le plan des versions comprenant les corrections de ces 
dysfonctionnements. 

Fiabilite des serveurs 

La fiabilite des serveurs est une mesure de duree de service ininterrompu. La fiabilite des serveurs est 
fonction inverse du nombre de defaillances materielles et logicielles qui provoquent Finterruption du 
service dans un laps de temps. Sous certaines hypotheses, largement acceptables pour les architectures 
orientees services, la fiabilite se mesure en termes de mean time to failure (MTTF), c'est-a-dire le 
temps moyen de fonctionnement non interrompu du serveur. 

Disponibilite 

La disponibilite est la propriete qui represente la capacite d'une application prestataire de services a 
etre en service, a savoir etre active et prete a pourvoir le service detaille dans le contrat. La disponibilite 
se mesure comme la probabilite d'un prestataire d'etre en service. 

II existe une relation evidente entre disponibilite et fiabilite. L'indisponibilite d'un service est la 
somme des temps d' arret constates pour chaque interruption de la prestation sur un laps de temps 
donne. Elle est done fonction du nombre d' interruptions et des delais de retablissement du service en 
cas d'interruption {time-to-repair, a savoir le temps qu'il faut pour retablir la disponibilite d'un 
service en cas de defaillance). 

Pour ameliorer la disponibilite, il faut augmenter la fiabilite (diminuer le nombre d' interruptions) et 
diminuer le temps de retablissement du service. Sous certaines hypotheses, largement acceptables 
pour les applications orientees services, la disponibilite est fonction du rapport entre le mean time to 
failure (MTTF), le temps moyen de continuite du service et le mean time to repair (MTTR), le temps 
moyen de retablissement du service. La disponibilite (A) est done definie comme : 

A = MTTF / (MTTF + MTTR) 

Le tableau suivant presente une classification des systemes par niveau de gestion de la disponibilite 
de service. 

Classification par niveaux de disponibilite de service 



Niveau de gestion de la 
disponibilite de service 


Classe du 
systeme 


Disponibilite 


Indisponibilite a 
lannee 


Indisponibilite 
a la semaine 


Non gere 


1 


= 90% 


< 52 560 minutes 


< 1008 minutes 


Gere 


2 


= 99% 


< 5 256 minutes 


< 101,08 minutes 


Bien gere 


3 


= 99,9% 


< 526 minutes 


< 10,11 minutes 


Tolerant aux pannes 


4 


= 99,99% 


< 53 minutes 


< 1,01 minutes 


Haute disponibilite 


5 


= 99,999% 


< 5 minutes 


<0,1 minutes 


Tres haute disponibilite 


6 


= 99,9999% 


<0,5 minutes 


< 0,01 minutes 


Tres tres haute disponibilite 


7 


= 99,99999% 


< 0,05 minutes 


< 0,001 minutes 
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Continuite 

La continuite de service precise les modalites de gestion des arrets et des reprises de la prestation de 
service. 

Nous distinguons quatre niveaux de gestion d' arret du service, correspondant a quatre niveaux de 
capacite de configuration dynamique du prestataire : 

• gestion d' arret niveau ; 

• gestion d' arret niveau 1 (try on failure) ; 

• gestion d' arret niveau 2 (notification) ; 

• gestion d' arret niveau 3 (fail over). 

La mise en ceuvre successive des differents niveaux de gestion d' arret demande un niveau croissant de 
capacite de F application prestataire a configurer dynamiquement les elements de la prestation a pour- 
voir, et, reciproquement, un niveau decroissant de capacite du client a configurer dynamiquement les 
elements d' utilisation de la prestation. Une discussion generate sur les capacites de configuration 
dynamique des architectures orientees services est presentee dans le chapitre 4. 

La gestion de la reprise est en relation avec certaines caracteristiques fonctionnelles et operationnelles 
du service, et notamment son caractere stateful ou stateless, c'est-a-dire avec ou sans etat. 

Gestion d'arret 

Gestion d'arret niveau 

Au niveau il n'y a pas de gestion d'arret. Le service est disponible ou non et, en cours d' utilisation, 
son indisponibilite est revelee par une erreur de fonctionnement de la prestation ou le silence du pres- 
tataire. La charge de la continuite de service repose entierement sur F application cliente, qui doit 
deceler Finterruption de service et rechercher eventuellement des prestataires de remplacement. 

Gestion d'arret niveau 1 (try on failure) 

Au niveau minimal de gestion de la continuite, le prestataire s'engage a mettre en ceuvre un serveur 
de remplacement dans un certain delai (qui peut etre reduit a zero par une configuration redondante). 
Si les serveurs sont redondants, la continuite de service est assuree, au prix eventuel d'une degradation 
temporaire d'autres parametres du niveau du service (sa performance, par exemple). 

La presence de ce type d' engagement de continuite comme clause du contrat autorise Fapplication 
cliente a mettre en place une strategie dite try on failure. Cette strategie consiste a rechercher, en cas 
de defaillance du serveur auquel le client est lie en cours d' utilisation du service, un autre serveur 
fournissant un service equivalent, via la decouverte sur un annuaire ou par d'autres moyens. 

Cette strategie partage la charge de reconfiguration dynamique de la relation de service entre le client 
et le prestataire, avec un effort important cote client (qui doit rechercher un nouveau point d'acces et 
instrumenter a nouveau la relation de service). 

Gestion d'arret niveau 2 (notification) 

Un autre mode de gestion de la discontinuite est la notification de la part du prestataire au client de 
F arret (programme ou impromptu) du serveur, avec communication du point d'acces (port de reception) 
du serveur de remplacement. 
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La gestion de la notification de discontinuity demande la mise en ceuvre de la part du prestataire et du 
client d'une interface et eventuellement d'un protocole de conversation specifique. La notification ne 
fonctionne que pour des arrets programmes ou pressentis (qui peuvent aussi etre programmes dyna- 
miquement suite a une situation de degradation irreversible du serveur). Le mode try on failure peut 
fonctionner comme strategie complementaire pour les arrets impromptus. 

Cette strategie partage la charge de reconfiguration dynamique de la relation de service entre le client 
et le prestataire, avec un effort important cote prestataire (le client doit simplement instrumenter a 
nouveau la relation de service avec les nouveaux points d'acces fournis par le prestataire). 

Gestion d 'arret niveau 3 (fail over) 

Le niveau le plus eleve d'engagement de continuite de service est Fengagement defail over, c'est-a- 
dire de remplacement automatique et transparent du serveur, qui ne demande aucune action specifique 
de la part du client. 

La charge de la reconfiguration dynamique de la relation de service repose entierement sur le prestataire. 

Gestion de la reprise 

Le probleme de la gestion de la reprise (apres 1' arret) se pose differemment selon les caracteristiques 
fonctionnelles et operationnelles de la prestation de services. Une premiere distinction est celle des 
services avec ou sans gestion d'etat {stateful ou stateless). 

Un service est dit stateless si la prestation de service est faite d' unites de travail atomiques et inde- 
pendantes les unes des autres (exemple : le service consiste a repondre a des requetes unitaires de 
nature informationnelle comme des selections multicriteres). 

Un service est dit stateful s'il consiste a executer une tache produisant des informations, des changements 
d'etat et des effets de bord pilotes par un dialogue long entre client et prestataire. 

Un service stateless est fait de prestations unitaires qui n'ont aucune relation entre elles. Un service 
stateful est fait de prestations complexes qui necessitent de la pail du prestataire la gestion d'un 
contexte d' interaction. 

Service stateless 

II n'y a pas de gestion de reprise a proprement parler, separee de la gestion de la fiabilite des echanges, 
pour un service stateless. Les differents niveaux de gestion des arrets peuvent etre mis en ceuvre, 
avec, pour les niveaux 1 et 2, des consignes particulieres pour les prestations en realisation au 
moment de 1' arret impromptu. 

Service stateful 

La gestion de la continuite d'un service stateful conceme la gestion de la tache effectuee par le prestataire 
pour la realisation du service et, eventuellement, des conversations ou sessions qui ont ete interrompues 
par F arret impromptu du service. Nous faisons une distinction entre une conversation, qui est tenue par 
un protocole de conversation etabli, et une session, qui est un echange libre d'actes de communication 
dans lequel les interlocuteurs gardent et eventuellement s'echangent les contextes applicatifs respectifs. 

Pour F arret programme, s'il n'y a pas d'engagement Aefail over, un serveur peut se desengager du 
service en terminant normalement son activite et les conversations/sessions en cours, et en refusant 
toute tentative d'engager une nouvelle conversation/session, apres avoir eventuellement notifie aux 
clients son arret et le serveur de remplacement. 



L'architecture orientee services 

Premiere Partie 

La gestion des arrets impromptus se traduit, en cas de fail over, par la capacite pour le serveur de 
secours de recuperer de facon transparente pour les clients les etats d'avancement de la tache et done 
d'eventuelles conversations/sessions en cours. Cela implique d'abord la persistance des etats, des 
taches et des conversations/sessions sur des memoires de masse partagees entre le serveur primaire et 
le serveur de secours (eventuellement redondantes pour obtenir la durabilite) ou la gestion doublee de 
la prestation avec le serveur de secours qui duplique les traitements du serveur primaire. 

Si le serveur de secours n'a pas acces, d'une facon ou d'une autre, aux etats d'avancement persistants 
des taches et des conversations/sessions, ces dernieres sont perdues ou en echec (comme dans le cas 
des transactions dynamiques, voir plus loin la section Gestion des transactions). 

Le serveur de secours peut ne pas offrir un service de remplacement transparent : il y a done bel et 
bien arret du service. En revanche, s'il a acces aux etats d'avancement persistants des taches et des 
conversations/sessions, il peut offrir la fonction de reprise a chaud. Apres redemarrage, les taches et 
les sessions/conversations en cours sont reprises a leur point d' interruption ou au dernier point de 
reprise proche du point d' interruption. 

Pour etre capable de beneficier de la fonction de reprise a chaud, le client doit a son tour garder les 
contextes des sessions interrompues (ou etre pret a les recevoir du serveur, s'il pourvoit ce service 
annexe) et done etre capable de reprendre la conversation/session au point d' interruption ou, a 
l'inverse, arreter brutalement la session en cours et en reinitialiser une autre. Par ailleurs, le presta- 
taire peut, pour des raisons de securite et de surete du service apres un arret « en catastrophe », 
effectuer une reprise afroid de l'activite, sans conservation des contextes des taches et sessions/ 
conversations actives avant l'arret, ce qui equivaut au demarrage d'un serveur de secours ne gerant 
pas la continuite de service. 

Gestion des transactions 

La prestation de service est un ensemble de resultats (informations, etats, effets de bord) de l'activite 
d'une application prestataire, directement ou indirectement exploitables par une application cliente. 

La gestion de transactions touche directement la qualite de ces resultats, et notamment la veracite et 
la coherence des informations ainsi que la coherence, la persistance et la durabilite des etats, qui 
peuvent etre compromises par : 

• les defaillances du prestataire de service lors de la production desdits resultats ; 

• la concurrence d' acces de la part de plusieurs clients aux informations, etats et effets de bord geres 
par le prestataire. 

Avec la mise en ceuvre de la gestion des transactions, le service s'organise sous forme d'unites de 
prestation appelees transactions. Les transactions ont certaines caracteristiques techniques qui 
permettent a la prestation de service de presenter divers degres de tolerance aux defaillances et divers 
niveaux de gestion de la concurrence des prestations. II est important de savoir que la tolerance aux 
defaillances et la gestion de la concurrence ont un impact majeur sur une caracteristique critique du 
comportement au niveau fonctionnel du prestataire : la coherence fonctionnelle des informations, des 
etats et des effets de bord. 

Bien entendu, la coherence fonctionnelle doit etre avant tout assuree par le modele fonctionnel (les 
regies de gestion metier) et son implementation (la traduction correcte de ces regies dans un code 
executable). Aucune coherence fonctionnelle ne peut etre garantie par un modele fonctionnel incoherent 
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ou mal implemente : il s'agit d'une condition necessaire. Mais la coherence du modele fonctionnel et 
de son implementation n'est pas une condition suffisante pour garantir la coherence fonctionnelle du 
comportement du prestataire a cause des problemes qui peuvent surgir des defaillances du prestataire 
et de la concurrence d'acces au service. 

Meme dans un monde ideal, dans lequel il n'y aurait aucune defaillance des composants materiels 
et logiciels, ni du prestataire ni du client, la problematique de la gestion des transactions se pose- 
rait car le partage des ressources, et done la concurrence d'acces, peut etre une caracteristique 
primaire et recherchee des fonctions du service (par exemple lorsqu'elles gerent l'allocation 
concurrente et « en temps reel » de ressources physiques limitees, comme des places sur un avion). 
La gestion des transactions garantit, dans une certaine mesure, que le comportement fonctionnel 
du prestataire de service reste coherent meme en presence de ses propres defaillances et de la 
concurrence d'acces au service. 

Une transaction est une unite de prestation de service qui possede les caracteristiques suivantes : 

• L'atomicite : l'ensemble des changements d'etat des differentes ressources, effectues dans une 
transaction, constitue une transition atomique (tout ou rien), elle est executee entierement ou bien 
elle n'a pas lieu. Sont visibles, a l'exterieur de la transaction, seulement l'etat initial et l'etat final : 
les etats intermediates sont temporaires et inaccessibles. Malheureusement, les effets de bord ont 
comme caracteristique V irreversibility, mais les systemes de gestion de transaction offrent des 
instruments permettant de gerer au mieux l'irreversibilite des effets de bord executes dans le cadre 
d'une transaction. 

• L' isolation : la transition d'etat a lieu en isolation totale, sans interference avec d'autres trans- 
actions portant sur les merries ressources et sollicitees par d'autres clients. Pour obtenir 1' isolation 
de la transaction, les ressources impliquees doivent etre verrouillees, a savoir rendues partiellement 
ou totalement inaccessibles aux autres transactions concurrentes pendant la duree de la transaction. 

• La durabilite : le changement d'etat des ressources, effet d'une transaction correctement executee 
et terminee, est durable, il doit done survivre a toute defaillance et indisponibilite du prestataire 
assurant le service. La seule facon de changer cet etat durable est l'execution autorisee et correcte 
d'une nouvelle transaction. 



Precision sur la coherence fonctionnelle 

L'ensemble des proprietes d'une transaction est appele en anglais ACID, acronyme d'Atomicity, Consistency, 
Isolation et Durability. Nous faisons la distinction entre les proprietes operationnelles (comme l'atomicite, isolation 
et la durabilite) et la coherence {consistency) des etats geres, qui est une propriete fonctionnelle. Les proprietes 
operationnelles sont assurees par des mecanismes techniques tandis que la coherence doit etre prise en change 
par les regies de gestion. 

Des systemes evolues de gestion transactionnelle peuvent apporter des outils de support au maintien de la 
coherence fonctionnelle, comme I'engagement a declencher automatiquement, dans le cadre d'une transaction, 
toutes les regies de gestion dont les conditions de declenchement s'apparient avec un evenement metier. 
Ces systemes sont evidemment non responsables de la qualite fonctionnelle et de la completude logique des 
regies declenchees. 
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La problematique de la gestion de transactions se pose pour les applications orientees services a deux 
niveaux, que voici : 

• les transactions centralists : un prestataire assure le caractere trans actionnel de F unite de prestation 
que le client lui demande d'executer par simple requete, eventuellement par agregation (transparente 
pour le client) d'autres services (voir figure 3-2) ; 
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Figure 3-2 

Le prestataire du service agrege est coordinateur de la transaction repartie. 

• les transactions reparties : 1' unite de travail transactionnel resulte des activites coordonnees de 
plusieurs prestataires (voir figure 3-3). 

II est important de noter que les transactions reparties sont une technique de mise en ceuvre de services 
agreges, a savoir de services qui resultent de 1' agregation d'autres services. La figure 3-2 illustre le 
cas d'un prestataire de service (la centrale de reservation) qui pourvoit un service agrege de reserva- 
tion de places bloquees avec paiement immediat et qui, pour ce faire, coordonne une transaction 
repartie aupres d'autres prestataires de services de reservation et de paiement. L'application cliente a 
un seul interlocuteur qui se charge de garantir les proprietes trans actionnelles (atomicite, consistance, 
isolation et durabilite) de l'unite de prestation qui comprend la reservation de place et le paiement. 

Le client invoque une unite de prestation transactionnelle aupres du prestataire (la centrale de reser- 
vation), mais il peut tout a fait ignorer que le prestataire realise la prestation en solitaire ou que cette 
prestation est le resultat d'une agregation de services. L'agregation de services sera analysee plus en 
detail dans le chapitre 4. 

En revanche, le client peut interagir directement avec plusieurs prestataires de services mais souhaiter 
traiter 1' ensemble des prestations comme une transaction. Dans ce cas, un prestataire de services 
techniques (le coordinateur) se charge de mettre en ceuvre le protocole qui garantit les proprietes 
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transactionnelles de F ensemble de ces prestations : la reservation de place et le paiement constituent 
une unite de prestation atomique, consistante, isolee et durable. 

La figure 3-3 illustre l'utilisation d'un service technique de coordination de transactions reparties. 
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Figure 3-3 

Le client et les prestataires s 'appuient sur un prestataire de sendees de coordination d 'applications reparties. 



Les transactions centralisees 

Dans le contrat de service, le prestataire s'engage sur tout ou partie des proprietes transactionnelles 

de certaines unites de prestation. Ces unites de prestation sont le resultat de taches accomplies par le 

prestataire sur requete explicite du client. 

II y a deux types d'interactions possibles avec un prestataire qui pourvoit des services transactionnels 

centralises : 

• les transactions implicites (ou statiques) ; 

• les transactions explicite s (ou dynamiques). 

Transactions implicites (statiques) 

Dans l'approche des transactions implicites, une requete de la part du client declenche le demarrage 
d'une unite de prestation qui est executee comme une transaction par le prestataire. L'unite de presta- 
tion invoquee : 

• soit se termine par un succes, 

• soit s'interrompt ou se termine par un echec (F interruption etant equivalente a Fechec). 
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Le succes veut dire que l'unite de prestation s'est entierement deroulee (atomicite), dans des bonnes 
conditions d' isolation, et que ses effets sont durables (a savoir que les etats produits ne peuvent etre 
changes que par d'autres transactions successives invoquees par les ayants droit). 

L'echec du traitement transactionnel signifie que, du point de vue du client et par rapport aux etats 
geres par le prestataire, il ne s'est rien passe (sauf inscription dans le journal). 

Le prestataire repond done a la requete soit par un compte rendu de succes, enrichi eventuellement de 
donnees metier rassemblees et/ou calculees par la transaction, soit par un compte rendu d'echec. 

Des clauses du contrat de service peuvent expliciter les proprietes transactionnelles de l'effet 
pragmatique d'un acte de communication. 

Transactions explicites (dynamiques) 

L'approche des transactions explicites permet au client de piloter lui-meme la composition et le 
deroulement de l'unite de prestation a l'execution (transactions dynamiques). La transaction expli- 
cite impose la mise en ceuvre dans 1' interface client/prestataire d'un protocole de conversation 
(protocole de confirmation en une etape) qui ne sera pas detaille dans ce chapitre, mais qui 
comporte idealement au moins trois actes de communication permettant le pilotage d'une tache 
trans actionnelle : 

• start : par cet acte, le client demande le debut d'une unite de prestation qui doit etre geree comme 
une transaction par le prestataire. Le prestataire, par un compte rendu de succes, marque son 
acceptation a demarrer l'unite de prestation transactionnelle. 

• commit : le client demande la fin de l'unite de prestation et sa confirmation comme transaction. Si 
le prestataire retourne un compte rendu de succes, tous les traitements invoques ou provoques par 
le client entre start et commit font partie de l'unite de prestation geree comme une transaction. Un 
compte rendu d'echec rapporte l'echec de la transaction pour des raisons propres au prestataire : 
dans ce cas, e'est comme si l'ensemble des traitements invoques ou provoques par le client et 
effectues par le prestataire entre start et commit n'avait pas eu lieu (sauf inscription sur des 
journaux). 

• rollback : le client demande Vannulation de la transaction, a savoir la fin de l'unite de prestation et 
l'effacement de toutes les consequences des traitements invoques ou provoques par le client et 
executes par le prestataire apres le start (a l'exception des inscriptions dans les journaux). Un 
compte rendu d'erreur du rollback peut plonger le client dans l'incertitude : l'effacement de toutes 
les consequences des traitements invoques ou provoques depuis le start a-t-il ete effectue ou non ? 

Une variante de ce protocole est le start implicite : le client ouvre une session transactionnelle avec 
le prestataire et est d'emblee place dans une unite de prestation transactionnelle dynamique : tous les 
traitements qu'il invoque aupres du prestataire sont places dans une transaction qui se termine par 
une confirmation ou une annulation explicite. Ces primitives marquent aussi implicitement le start de 
l'unite de prestation transactionnelle suivante, et cela jusqu'a la cloture de la session. 

Dans le fonctionnement par transaction explicite, le protocole de confirmation en une etape fait partie 
de l'interface du service. Les actes de communication techniques du protocole de confirmation en 
une etape (start, commit, rollback) sont independants de la specialisation metier du service. 
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La presence, dans 1' interface du service, du protocole de confirmation en une etape, demande de 
preciser, pour chaque acte de communication realise sur initiative du client, si celui-ci peut s'inscrire 
dans le deroulement d'une transaction, a savoir entre un start et un commit, et done si le prestataire 
s'engage a traiter les changements d'etat de ressources provoques par de tels actes dans le cadre 
d'une gestion transactionnelle. Un service dont chaque prestation peut s'executer dans le cadre d'une 
transaction est dit service transactionnel. 

En resume, les prestations de service organisees sous regime transactionnel par le prestataire sont 
generalement invoquees par le client (meme si elles peuvent etre declenchees par d'autres moyens, 
par exemple sur des sollicitations de l'environnement). Le client, alors, invoque la prestation trans- 
actionnelle via une seule requete (transaction implicite) ou la pilote par une succession de requetes 
encadrees par des primitives de gestion de la transaction {start, commit, rollback). 

Niveau d'isolation des lectures 

Les prestations de services d' interrogation de bases d' informations constituent une des sources 
principales de charge des systemes et un goulot d'etranglement pour la performance. Notamment, les 
interrogations pour l'aide a la decision et pour la constitution de rapports peuvent declencher des 
recherches sophistiquees et la consultation de beaucoup de donnees. 

Les verrous poses sur les donnees concemees, pour dormer une vision coherente (un etat) de ces memes 
donnees, aggravent le deficit de performance, car ils provoquent la mise en sequence des mises a jour. 

Generalement, trois niveaux de verrouillage des lectures (niveaux d'isolation) sont adoptes : 

• niveau 1 : aucun verrouillage (lectures « sales ») ; 

• niveau 2 : stabilite du curseur ; 

• niveau 3 : isolation parfaite. 

Le niveau d'isolation 3 satisfait toutes les caracteristiques de la gestion transactionnelle : les verrous 
sont poses les uns apres les autres et sont leves seulement au commit. Le niveau 3 applique done le 
principe de verrouillage en deux phases qui veut que dans une transaction aucun verrou ne soit leve 
avant que tous les verrous n'aient ete poses. Les verrous sont poses au fur et a mesure des lectures et 
ils sont leves tous ensemble a la confirmation de la transaction : les informations retoumees represented 
un etat coherent. 

Le niveau d'isolation 1 ne pose aucun verrou : il ne garantit done ni la coherence ni la veracite 
des informations car 1' interrogation peut lire des valeurs incoherentes entre elles et non validees, 
lesquelles, peut-etre, n'atteindront jamais l'etat de confirmation (cela depend de la technique de mise en 
ceuvre de la base). Cette situation est tolerable lorsque ni la veracite ni la coherence des donnees indivi- 
duelles ne sont reellement importantes : les variations des donnees sont faibles et 1' interrogation donne 
une vue d'ensemble. Cette approche est evidemment tres avantageuse pour la performance car : 

• la gestion des verrous est coiiteuse en soi ; 

• la pose des verrous met en sequence les transactions de lecture avec les transactions de modification. 

Le niveau d'isolation 2 correspond a une strategie intermediate : le verrou en lecture est pose sur la 
donnee seulement pendant le temps de la lecture (le curseur est done stable et la donnee lue a ete validee), 
mais il est leve immediatement apres. Le principe du verrouillage en deux phases n'est pas respecte. De 
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ce fait, l'ensemble de donnees ainsi obtenu peut etre incoherent, mais les donnees prises separement ont 
ete vraies a un certain instant. Cette strategie est bonne pour la performance (presque aussi bonne que le 
niveau 1), sans le defaut majeur du niveau 1 qui est le risque sur la veracite des donnees. 

Pour chaque requete d' interrogation, le contrat peut specifier le niveau de verrouillage offert (qui peut 
etre aussi un parametre de la requete). 

Gestion des transactions et fiabilite des echanges 

Qu'il travaille en transaction explicite ou implicite, apres chaque invocation, le client entre dans un 
etat d'attente a priori indefini, gere par un delai d'attente maximal {timeout). Si la reponse est recue 
avant la fin de la periode d'attente, le client prend connaissance du succes ou de Fechec de F execu- 
tion de la transaction entiere (transaction implicite) ou de Foperation faisant partie de la transaction 
(transaction explicite). Compte tenu des caracteristiques de la gestion trans actionnelle citees ci- 
dessus, le client est dans un etat de certitude sur le resultat de cette execution. En revanche, si le delai 
d'attente maximal est depasse sans reception de la reponse, le client entre dans un etat d' incertitude 
sur Fetat des ressources gerees par le prestataire. 

Meme dans le cas simple de transaction implicite invoquee par un appel synchrone de procedure 
distante, le depassement du delai d'attente de reponse plonge le client dans un etat d' incertitude. 
L' incertitude peut toucher : 

• la reussite ou non de la transmission de F invocation du client au prestataire ; 

• la prise en compte ou non par le prestataire de F unite de prestation a realiser ; 

• le succes (confirmation) ou Fechec (annulation) de la transaction ; 

• le declenchement ou non de la transmission du retour de la part du prestataire ; 

• la reussite ou non de la transmission du retour du prestataire au client. 

En resume, dans les cas de depassement du delai maximal d'attente de reponse, F appelant peut etre 
dans Fincertitude la plus totale sur l'execution de la prestation invoquee car il ne sait pas si le depas- 
sement du delai d'attente est du simplement a un temps de latence excessif ou si une defaillance s'est 
produite dans la chaine (il ne connait pas non plus le « lieu » ou la defaillance se serait produite). 

Le traitement exhaustif de la pail du client, au niveau applicatif, de tous les scenarios de defaillance 
et de temps de latence possibles impose une conception logicielle d'une tres grande complexite. La 
solution alternative du probleme est Futilisation de technologies d'echange fiable. La fiabilite des 
echanges, que nous avons evoquee dans la section Fiabilite, prend tout son sens lorsqu'elle est 
couplee avec la gestion des transactions. 

Un service trans actionnel qui gere des files d'attente des messages en entree et en sortie, traite l'ensemble 
des operations (prelever la requete de la file d' entree, traiter la requete transactionnelle, poser la reponse 
dans la file de sortie) comme une transaction imbriquee. II faut en effet pouvoir distinguer : 

• les echecs techniques : de la transaction d' extraction de la file d' entree, de la transaction applicative 
imbriquee, de la transaction d' insertion dans la file de sortie ; ces echecs techniques demandent une 
annulation de la transaction globale, a la fin de laquelle la requete est encore dans la file d' entree ; 

• Fechec applicatif (violation des regies de gestion) de la transaction applicative imbriquee, qui 
demande son annulation ; la transaction globale continue car il faut inserer dans la file de sortie le 
compte rendu d'echec de la transaction applicative. 
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Les transactions reparties 

La confirmation en deux etapes 

La garantie des proprietes transactionnelles d'une unite de prestation qui comprend des taches executees 
par plusieurs applications reparties peut etre obtenue au moyen de protocoles connus et mis en ceuvre 
dans les systemes transactionnels et les systemes de gestion de bases de donnees du marche. Le plus 
populaire de ces protocoles est la confirmation en deux etapes (Two-phase commit). 



Two-phase commit 

Le protocole de confirmation en deux etapes (two-phase commit ou 2PC) a ete introduit par plusieurs moniteurs tran- 
sactionnels du marche et finalement normalise par les consortiums OSI (Open System Interconnection) et X/Open. 
X/Open a defini le X/Open Distributed Transaction Processing standard. Le standard propose une architecture sur 
la base d'un transaction manager et plusieurs resource managers, un protocole de coordination entre les transac- 
tion manager, les resource managers et les applications impliquees, ainsi qu'une API (XA interface). 



Le protocole de confirmation en deux etapes introduit une distinction entre : 

• une premiere etape de preparation a la confirmation de la transaction repartie (prepare-to- 
commit) ; 

• une deuxieme etape de confirmation proprement dite {commit), ou d'annulation (rollback). 

Ces deux etapes sont orchestrees par un coordinateur (une application participate qui fait office de 
prestataire de services de coordination) qui, pour le compte du client, coordonne l'execution des 
taches de plusieurs prestataires de services intervenant dans la transaction repartie (voir figure 3-3). 
Sur demande du client, lorsque l'unite de prestation est a sa fin et s'est deroulee correctement, le 
coordinateur effectue les taches suivantes : 

• il invoque successivement aupres de tous les participants prepare-to-commit ; 

• lorsqu'il a recu les comptes rendus de succes de la part de tous les participants, il invoque aupres 
d'eux commit et communique au client le succes de la transaction repartie ; 

• si le coordinateur recoit un compte rendu d'echec de la part d'au moins un des participants, il 
invoque le rollback aupres de tous les participants sans exception, et communique au client l'echec 
de la transaction. 

Sans entrer dans les details du protocole, F integration d'un coordinateur dans une architecture orientee 
services presente plusieurs problemes, qui se rapportent tous a la notion de couplage entre applications 
orientees services : 

• La presence d'un agent qui interprete le role de coordinateur introduit une dose de centralisation a 
F architecture. II faut done que les participants acceptent que l'une des applications joue ce role 
central. II n'est pas exclu que, dans le futur, des agents logiciels jouant le role de tiers de confiance 
puissent pourvoir professionnellement le service de coordination de transaction reparties. 

• Entre la preparation a la confirmation (prepare-to-commit) et la confirmation (commit), chaque 
participant doit maintenir verrouillees les ressources impliquees dans la transaction pour en 
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garantir F isolation. Cette periode peut etre arbitrairement longue, a cause des temps de reponse des 
applications participantes et des temps de latence. Dans cette periode, chaque participant est dans 
un etat d' incertitude : il a accepte le prepare-to-commit, il est pret a accepter Fordre suivant, qui 
peut etre commit ou rollback, selon la decision du coordinateur. S'il y a arret par defaillance du 
coordinateur, le participant est bloque a jamais, ses ressources sont verrouillees et il ne peut ni 
valider la transaction ni Fannuler. Une intervention manuelle d'un administrateur est necessaire 
pour debloquer la situation. 

• S'il y a defaillance d'un participant entre prepare-to-commit et commit, la reprise de ce participant 
ne peut etre effectuee de facon independante : c'est le coordinateur qui doit lui communiquer a 
nouveau la decision qu'il avait prise lorsque le participant etait en interruption de service. Cette 
situation implique un couplage fort entre le coordinateur et chacun des participants (ainsi que la 
possibilite d' intervention manuelle d'un administrateur). 

• Le niveau global de qualite d'un service qui met en ceuvre des transactions reparties (la perfor- 
mance, la fiabilite fonctionnelle et operationnelle, la disponibilite ainsi que d'autres caracteristiques 
de qualite de service) est pratiquement impose par la plus faible des applications participantes. Par 
exemple, le taux de succes technique des transactions reparties qui impliquent un ensemble fige 
d' applications participantes est par definition inferieur ou egal au taux de succes des transactions 
chez la plus faible des applications participantes. Cette situation peut etre inacceptable par le client 
comme par les autres prestataires participant a la transaction qui pourvoient un service de niveau 
de qualite superieure. 

Les contraintes et les problemes listes ci-dessus peuvent se reveler insupportables pour des applications 
qui doivent gerer en meme temps des ressources critiques a forte concurrence d'acces et un debit 
eleve de requetes. L'orientation generate aujourd'hui est que l'application de protocoles synchrones 
de coordination de transactions, comme la confirmation en deux etapes, n'est pas appropriee aux 
AOS « faiblement couplees » et dynamiques (qui seront presentees dans le chapitre 4 de cet ouvrage). 
Des approches plus realistes affaiblissent une ou plusieurs des proprietes transactionnelles de Funite 
de travail repartie (notamment l'atomicite et l'isolation) : elles reposent sur l'approche dite des 
transactions compensatoires. 

Les transactions compensatoires 

Une transaction compensatoire T 1 est censee defaire « logiquement », done compenser les changements 
d'etat de ressources effectues par la transaction T, garantissant ainsi que le systeme se retrouve dans 
un etat fonctionnellement coherent et pertinent. 

Attention, l'execution d'une transaction compensatoire, meme immediatement apres la transaction 
« a compenser » n'est pas une annulation de celle-ci, qui a bien eu lieu entierement et dont les effets 
restent durables, Fetat des ressources E', apres l'execution reussie de T suivie par l'execution reussie 
de T 1 , n'est generalement pas identique a Fetat des ressources E immediatement avant l'execution 
deT. 
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En fait, l'execution reussie de T sur l'etat E provoque une transition de l'ensemble des ressources 
impliquees vers l'etat E { . Si la transaction compensatoire T 1 passe immediatement apres Tl, et si la 
compensation a le meme effet que Fannulation de la transaction a compenser, Fensemble de ressources 
revient a l'etat E (figure 3-4). 
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Figure 3-4 

Transaction compensatoire qui annule les effets de la transaction a compenser. 

Mais Ej est un etat du systeme generalement accessible aux autres transactions Tj, T 2 , T 3 etc. 
concurrentes de T 1 , qui provoquent a leur tour des transitions respectivement vers les etats E 2 , E 3 , E 4 . 
La transaction compensatoire T 1 peut intervenir sur n'importe quel etat E N successif de E { et produit 
par la sequence de transactions qui se sont glissees entre T et T _1 (figure 3-5). La transaction 
compensatoire T 1 doit done etre concue pour tenir compte de cette situation. 




Figure 3-5 

Execution d'une transaction compensatoire dans le cas general. 



Un service trans actionnel bien concu doit proposer systematiquement des transactions compensatoires. 
Les moteurs de gestion des transactions prennent en compte les violations des regies de gestion et les 
defaillances techniques pour provoquer automatiquement Fannulation de la transaction afin d' assurer 
la coherence de l'etat des ressources. En revanche, ces serveurs ne peuvent evidemment pas prendre 
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en compte les erreurs du client (les operations licites et autorisees qui amenent le systeme dans un 
etat coherent mais faux, comme celui dans lequel se trouve un compte bancaire apres virement d'une 
somme avec un zero de trop, resultat d'une faute de frappe). Les transactions compensatoires consti- 
tuent le seul mecanisme a disposition de l'application cliente (de l'utilisateur final, de l'administrateur) 
pour corriger ses propres erreurs. 

Dans Finterface d'un service trans actionnel qui propose des transactions compensatoires, il faut indiquer 
la relation entre les actes de communication qui declenchent respectivement une transaction et la 
transaction compensatoire associee. 

La mise en ceuvre des transactions reparties par transactions compensatoires affaiblit les caracteristiques 
trans actionnelles des unites de prestation, et notamment leur atomicite, mais permet d'eviter les problemes 
de couplage fort qui surgissent avec des protocoles synchrones comme la confirmation en deux etapes. 

La figure 3-6 illustre la mise en ceuvre de la reservation d'une place bloquee a l'aide des transactions 
compensatoires. Dans l'exemple, le paiement (R B ) suit la reservation (R A ). Si le paiement echoue, 
l'application Our Travels declenche la transaction compensatoire d'annulation (R A -1 )- 
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Figure 3-6 

Agregation de sendees avec transactions compensatoires. 



Transactions courtes et transactions longues 

L'orientation generate pour une architecture orientee services est done : 

• de garder l'approche de confirmation en deux etapes pour les transactions courtes synchrones, entre 
application en couplage fort, qui doivent imperativement etre traitees en temps reel ; 

• de derouler les autres transactions, surtout les transactions longues asynchrones (qu'il n'est pas 
imperatif de traiter en temps reel) comme des processus metier resultant de l'enchainement de tran- 
sactions unitaires. 



La qualite de service 

Chapitre 3 



Defaillance 



T, 




T 2 




T 3 



















--©- 






V 




V 




' 3 -' 







Figure 3-7 

Detournement de processus metier par transactions compensators. 



Dans le deuxieme cas de figure, la disponibilite des transactions compensatoires est une condition 
necessaire au fonctionnement de l'approche (figure 3-7). 

La pratique des transactions compensatoires devient indispensable avec la mise en ceuvre de processus 
automatises qui impliquent plusieurs services Web. En outre, le declenchement des transactions 
compensatoires a partir d'une interface homme/machine permet de reparer manuellement les erreurs 
et la mauvaise prise en charge des defaillances operationnelles de ces processus automatises. 



Technologies de services Web et gestion des transactions 

La gestion de transactions qui impliquent des services Web fait aujourd'hui I'objet d'une specification de la part du 
Business Transaction Technical Committee {http://www.oasis-open.org/committees/business-transactions) au sein 
de I'OASIS. II s'agit du Business Transaction Protocol V.1.0. Ce protocole est generique comme le protocole de 
confirmation a deux etapes, mais il est moins exigeant sur les caracteristiques transactionnelles des unites de travail 
reparties qu'il controle. 

Microsoft, IBM et BEA ont propose WS-Transaction, WS-Coordination, deux specifications complementaires de 
BPEL4WS {Business Process Execution Language for Web Services Version 1.0, 31 juillet 2002) pour traiter les 
caracteristiques transactionnelles des processus metier organises en workflow de services Web. Ces deux speci- 
fications permettent de mettre en oeuvre des transactions courtes synchrones (confirmation en deux etapes) et 
des transactions longues asynchrones. 

Le chapitre 20 de cet ouvrage est dedie a la gestion des transactions pour les services Web et presente WS-Trans- 
action et WS-Coordination ainsi que le protocole BTP. 



Gestion du service 

Le deroulement de la prestation de service peut etre gere de facon explicite si le prestataire assure des 
services annexes de gestion du service primaire objet du contrat : 

• un service de gestion du cycle de vie du service primaire (activation, suspension, redemarrage, 
arret) ; 

• un service de pilotage du service primaire via la modification dynamique des parametres de la 
prestation ; 
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• un service d' interrogation sur I'etat du service primaire, eventuellement double d'un service de 
notification des changements d'etat du service primaire de la part du prestataire, a savoir des 
evenements capables d'influencer le deroulement de la prestation ; 

• un service de journalisation des activites du service primaire et des services annexes, pour en 
assurer le suivi. 

Les services d'interrogation et de journalisation sont a la base du suivi de la realisation de la prestation 
et de sa conformite a 1' application du contrat (specifications fonctionnelles et operationnelles du 

service). 

Les services secondaires de gestion sont en meme temps un sujet extremement important pour le 
developpement d' architectures de services professionnels sur le Net, et un sujet difficile a conjuguer 
avec le caractere decentralise des architectures orientees services. Certaines fonctions de gestion des 
services peuvent etre mises en ceuvre soit directement par le prestataire, soit par des tiers specialises, 
soit par des intermediaires (le role d'annuaire, le role d'intermediaire a valeur ajoutee). 

La gestion explicite et dynamique du service est importante surtout pour la gestion de la continuite du 
service (exemple : notification d'un arret de maintenance non programme) et le choix dynamique des 
serveurs. 



Gestion des services Web 

La gestion a I'execution des services Web ( Web Service Management) est un sujet sur lequel le travail realise dans 
le cadre des technologies de services Web est encore a I'etat embryonnaire, meme si des offres commencent deja 
a apparaitre {http://www.talkingblocks.com). 

Hewlett Packard (http://www.hp.com) et webMethods (http://www.webmethods.com) ont publie une proposition de 
specification de services de gestion a I'execution des services Web : Open Management Interface Specification 
Version 1.0. 

IBM et http://www.globus.org (un acteur logiciel libre des architectures a grille d'ordinateurs) sont a I'origine de 
I'initiative Open Grid Service Architecture (OGSA), qui se propose d'integrer dans les architectures a grille des 
technologies de services Web, sur la base de la notion de Grid Service. Grid Service Specification est disponible 
sur http://www.globus.org/ogsa. Cette specification presente des fonctions de gestion du cycle de vie d'un Grid 
Service. 

II est important de noter que le concept de Grid Service se situe a un niveau different du concept de service dans 
une architecture orientee services. Un Grid Service est un processus virtuel qui s'execute sur une grille d'ordina- 
teurs et qui utilise done des ressources de calcul, de memoire vive et de stockage reparties sur la « grille ». C'est 
done une notion d'implementation. Une application orientee services peut etre mise en oeuvre par un Grid Service. 



Gestion du changement 

La gestion du changement touche le cycle de vie du logiciel du prestataire mettant en ceuvre le 
service : les dysfonctionnements connus, les evolutions demandees et le plan des versions (road map) 
incluant, pour chaque version, les corrections et les evolutions integrees. 

Les dysfonctionnements connus du service sont identifies et les eventuelles solutions de contournement 
du probleme pose sont documentees. 

Des mecanismes de signalement d' anomalies a I'execution peuvent etre integres au service (un meta- 
service de gestion d' anomalies, a I'execution ou en differe) ou offerts par un service tiers specialise 
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de signalement d'anomalies a l'execution. Le service de signalement d' anomalies garde une trace et 
une statistique des problemes souleves. 

En revanche, les demandes d' evolutions sont presentees par des utilisateurs du service, a savoir par les 
concepteurs, les developpeurs et les exploitants des applications clientes. Elles sont identifiees et even- 
tuellement annotees par des solutions de contournement au meme titre que les dysfonctionnements. 

Un engagement generalise de non-regression est totalement irrealiste et il semble difficile qu'il 
puisse apparaitre dans un contrat. En revanche, certains engagements ponctuels de non-regression 
sur des fonctions critiques du service peuvent figurer explicitement dans le contrat. 

La solution ideale est que le plan des versions, avec la description precise du contenu de chaque 
version prevue, en termes de solutions de problemes et des demandes d'evolutions, soit joint au 
contrat. Les eventuelles regressions (qui ne peuvent pas etre exclues a priori) y sont documentees. 

La liste des problemes et des demandes d' evolution, les reponses et les solutions de contournement, ainsi 
que le plan des versions sont publies dans un journal qui est edite a une periodicite etablie dans le contrat. 



Gestion des versions et technologie des services Web 

II n'y a pas aujourd'hui de specifications ni de technologies pour la gestion dynamique du versioning des services 
Web, a savoir des differents objets impliques dans le cycle de vie d'un service Web et notamment du contrat de 
service et des applications prestataires. 



La gestion du contrat 

Un chapitre autre que celui sur le contrat de service porte sur la gestion du contrat elle-meme. II est de 
portee plus juridique que technique et son utilisation est done plutot reservee aux contractants et a leurs 
representants. II comprend des sujets comme la duree du contrat, les mecanismes eventuels de reconduc- 
tion du contrat ainsi que les regies de sortie du contrat, pour le client, mais aussi pour le prestataire. 

Les regies de sortie du contrat pour le client sont sans doute liees au niveau effectif du service pourvu 
par le prestataire et notamment au decalage entre le niveau de service constate et les engagements de 
qualite de service contenus dans le contrat. 

Le niveau de service peut etre constate a partir de la mise a disposition de la part du prestataire de fonctions 
de gestion du service (voir la section « Gestion du service »), et notamment des fonctions de suivi. 

Les termes de I'echange 

Le contrat de service peut formaliser un service qui est fourni unilateralement par le prestataire. II 
peut aussi formaliser un service qui fait l'objet (un des termes) d'un echange. Le contrat decrit done 
les termes de I'echange entre le client et le prestataire du services. 

On peut facilement distinguer, par rapport aux termes de I'echange entre client et prestataire, trois 
families de services : 

1. Les services gratuits : ces services sont concedes a titre gracieux, aucune remuneration, ni en 
numeraire ni par d'autres moyens n'est prevue. Larticle du contrat sur la formalisation de 
I'echange est vide. 
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2. Les services payants : la remuneration est en numeraire. La partie formalisation de Fechange du 
contrat decrit en detail le mode de remuneration, ainsi que les modalites de paiement et de 
facturation et les eventuelles penalites. 

3. Les services troques : la prestation de services est executee en echange de prestations de services 
compensatoires et cet echange est formalise dans le contrat. L article sur les termes de Fechange 
contient les references croisees a d'autres contrats de service qui sont executes en echange. Des 
relations de service circulaires peuvent etre contractualisees par ce biais. 

Services payants 

Larticle sur les termes de Fechange est la partie financiere du contrat qui touche : 

• la remuneration du service, ses modalites (forfaitaire, a l'unite de prestation, etc.), ses prix ; 

• les modalites de paiement et de facturation du service, qui sont evidemment liees aux modalites de 
remuneration ; 

• les penalites, qui sont bien entendu applicables lorsque certains decalages entre le niveau du 
service constate et les engagements de qualite de service contenus dans le contrat sont etablis. 

Des services annexes de gestion en ligne de la comptabilisation, du paiement et de la facturation 
(ainsi que des penalites) peuvent etre decrits dans le contrat. Les services annexes sont soit offerts 
directement par le prestataire du service primaire, soit par un prestataire tiers. 

Plusieurs modeles de remuneration de la prestation de services peuvent etre envisages, mais ils sont 
tous reconductibles aux variantes et/ou aux combinaisons de deux modeles de base : 

• le prix forfaitaire ; 

• le prix a I 'unite de prestation ; 

Le prix forfaitaire est adapte a des usages reguliers et intensifs, avec une charge importante. En 
revanche, des clients qui font un usage impromptu et episodique d'un service peuvent preferer le prix 
a l'unite de prestation. 

Le prix a l'unite de prestation necessite en premier lieu la definition precise de ladite unite de prestation. 
II s'agit d'une definition operationnelle : une unite de prestation doit etre toujours identifiable et doit 
pouvoir etre comptabilisee. La definition d'une unite de prestation n'est pas toujours possible, et 
surtout la comptabilisation des unites consommees peut se reveler une tache complexe. 

Les systemes de facturation permettant de mettre en ceuvre le prix forfaitaire sont relativement 
simples. En revanche, le prix a l'unite de prestation peut exiger des systemes sophistiques de factura- 
tion non seulement de la part du prestataire mais aussi de la part du client (par exemple, a Finterieur 
d'une organisation pour determiner, a des fins de refacturation interne, qui consomme le service). Le 
prestataire peut fournir le service annexe de facturation detaillee. 

Le modele du prix a l'unite de prestation ne pourra s'affirmer qu'avec la mise en ceuvre de systemes 
sophistiques de comptabilisation et facturation. Ces systemes pourront etre proposes en tant que 
services tiers par des prestataires specialises, dechargeant le prestataire d'un service metier de la 
charge et de la responsabilite de leur mise en ceuvre. 
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Le prestataire du service metier pourra heberger sa facturation aupres d'un specialiste de la facturation 
des services remuneres a la consommation, capable d'appliquer les regies comptables dictees par 
plusieurs prestataires de services ou, a l'inverse, imposant ses regies et mecanismes propres de factu- 
ration aux prestataires qui veulent s'appuyer sur ses services. Ce service tiers de comptabilisation, 
paiement, facturation, pourra egalement agir en qualite de tiers de confiance vis-a-vis des clients et 
prestataires de services, garantissant la certification et la non-repudiation des prestations effectuees 
et, a l'inverse, la repudiation des prestations non effectuees. 

Un niveau ulterieur de complexite est introduit par la presence, dans le contrat, de penalites qui sont 
en general applicables a la non-satisfaction de la part du prestataire des niveaux de qualite de service 
prevus par le contrat. Comme pour le prix a la prestation, la non-satisfaction du niveau de qualite de 
service doit etre effectivement detectable, quantifiable et mesurable, pour qu'un systeme de penalites 
effectif puisse etre mis en ceuvre. Le tiers de confiance de facturation peut egalement se charger de la 
gestion des penalites, s'il a la capacite de constater les ecarts par rapport au niveau de qualite de 
service attendu. 

La concentration des systemes de facturation aupres de prestataires de billing exhibant des modalites, 
des regies et des mecanismes clairs et uniformes presente Favantage de simplifier la gestion pour les 
clients et les prestataires. 

Services troques 

Dans le cas des services troques, F article sur la formalisation de F echange cite la structure du troc et 
done reference les contrats qui definissent les services realises en echange du service objet du contrat. 
Par ce biais, une architecture orientee services n'est plus seulement un reseau de relations de services 
regies par contrat, mais devient en outre un reseau de contrats de services. L echange de services n'est 
plus implicite, il est formalise par contrat. 

Services mixtes 

II est toujours possible de concevoir des termes d'echange complexes, qui melangent des remunerations 
en numeraire et d'autres effectuees par echange de services. 

Conclusions 

Le contrat est un modele 

II est maintenant possible d'enoncer une definition concise de 1' architecture orientee services : une 
architecture orientee services est une architecture d' applications reparties, liees obligatoirement et 
exclusivement par des relations de service regies par des contrats. Une prestation de services est un 
ensemble de resultats, de taches accomplies par une application prestataire et exploitables par une 
application cliente (informations, etats, effets de bord). Le contrat contient une description du service. 

Le contrat de service est produit et consomme par les acteurs humains et les agents logiciels des 
clients, prestataires, tiers et intermediaires du service, impliques dans les differentes etapes des cycles 
de vie du contrat, du service, des applications prestataires, clients, tiers et intermediaires. 
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Les concepteurs, du cote prestataire comme du cote client, sont concernes par les trois sujets majeurs 
de la description du service : la description des fonctions, de l'interface et de la qualite du service. lis 
vont en faire une utilisation symetrique. 

Les descriptions des fonctions et de la qualite du service sont des descriptions qui touchent le niveau 
fonctionnel du comportement de 1' agent prestataire de service. La description de la qualite de service 
donne les caracteristiques operationnelles abstraites de la prestation de service, a savoir les caracte- 
ristiques operationnelles qui peuvent etre enoncees sans connaissance des choix d'implementation. 

La description de l'interface comprend une partie fonctionnelle (les actes de communication) et une partie 
implementation (le format des messages, etc.). L'integration dans le contrat du modele d'implemen- 
tation de l'interface est indispensable pour garantir l'interoperabilite des agents logiciels client, prestataire, 
tiers et intermediate. 

Le contrat de service est done : 

• un modele fonctionnel du service (fonctions, interface, qualite) ; 

• un modele d'implementation de l'interface du service. 

Le contrat de service est un modele partiel de 1' application prestataire du service (voir la figure 3-8) 
a double titre : 

• En tant que modele fonctionnel, il n'exprime que la « vue » specifique au service du modele 
fonctionnel prestataire. Non seulement 1' application prestataire peut realiser plusieurs services 
regentes par des contrats differents (dissemination de services), mais certaines parties du modele 
fonctionnel constituent des secrets de fabrication du prestataire et en tant que tels ne sont pas 
publiees dans le contrat de service. 

• En tant que modele d'implementation, il se limite au modele d'implementation de l'interface du 

service. 

Modele descriptif et modele directif 

Modeliser un systeme revient a simplifier sa representation et a formaliser un ensemble de regies qui 
decrivent de facon intelligible son comportement. 

Les modeles des systemes peuvent etre utilises comme : 

• modeles descriptifs ; 

• modeles directifs. 

Un modele descriptif est le modele d'un systeme existant. Son but est d' aider a la comprehension des 
fonctions, du comportement et de la structure du systeme. Un modele descriptif peut constituer la 
base d'un guide d' utilisation du systeme. 

Un modele directif 'constitue une specification du systeme, et represente done soit un guide a la realisation, 
lorsque le systeme est a batir, soit un guide a la validation, lorsqu'il faut confronter son comportement 
a une reference. 

Le contrat de service est utilise comme modele fonctionnel descriptif (guide d' utilisation) par le 
concepteur de 1' application cliente, qui doit integrer la prestation de service dans les traitements qu'il 
concoit et met en ceuvre dans son application. 
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Figure 3-8 

Le contrat de service contient un modele partiel du prestataire. 



Le contrat de service est utilise comme un modele fonctionnel directif (specification fonctionnelle, 
guide d' implementation) par le concepteur de F application prestataire, lequel doit developper une appli- 
cation qui doit agir, en tant que prestataire de service, en conformite au contrat de service. L' engagement 
contractuel sert de guide d'utilisation au client et de specification d'implementation au prestataire. 

L'activite de conception du logiciel prestataire prend en entree le contrat de service et produit en 
sortie un modele d'implementation du logiciel et de r infrastructure, L'activite de developpement de 
1' application prestataire prend en entree le modele d'implementation et produit en sortie un logiciel 
et une infrastructure. Le logiciel et 1' infrastructure engendrent a 1' execution un comportement de 
prestataire de service de l'application. 
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La figure 3-9 presente les relations entre modele fonctionnel, modele d' implementation, logiciel et 
application en execution. 
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Relations entre contrat, modele d' implementation, 



qiciel et application a V execution. 



Architecture orientee services et services Web 

Le terme « technologies de services Web » (au pluriel) designe un ensemble de technologies en 
evolution, basees sur des standards ouverts (non proprietaries) et aptes a la mise en ceuvre d' archi- 
tectures orientees services. II s'agit, a la base, de technologies de communication entre applications 
reparties, qui garantissent l'interoperabilite de ces applications dont les implementations sont 
heterogenes. 

Les technologies de services Web sont issues de la convergence de plusieurs courants : 

• les technologies d'integration d' applications d'entreprise (IAE) ; 

• les technologies des objets et composants repartis (CORBA, DCOM) ; 

• les technologies d'echange de documents electroniques (EDI) ; 

• les technologies World Wide Web, et notamment le URI, HTTP, HTML et XML. 

Le terme « service Web » denote une application qui met en ceuvre les technologies de services Web 
pour communiquer avec les autres applications. Une definition precise de « service Web » est proposee 
par le groupe de travail WS Architecture de la W3C Web Service Activity : 
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« Un service Web est une application logicielle, identiflee par un URI, dont les interfaces et les 
liaisons peuvent etre definies, decrites et decouvertes sous forme de documents XML. Un service 
Web met en ceuvre l'interaction directe avec d'autres agents logiciels par l'utilisation des messages au 
format XML, echanges sur des protocoles Internet. » (Web Services Architecture Requirements, W3C 
Working Draft, 19 August 2002 ; traduction de l'auteur) 

La relation entre l'emergence des technologies de services Web, du concept de service Web et l'essor 
du modele de F architecture orientee services est tres etroite : 

• Les concepts sous-jacents des services Web sont fortement marques par le modele de 1' architecture 
orientee services. 

• Les technologies de services Web permettent de construire, deployer, exploiter, maintenir, 
administrer des AOS a un niveau de generalite jamais atteint auparavant. 

• Les technologies de services Web permettent de mettre en ceuvre naturellement les AOS sur 
Internet. 

Le diagramme general des technologies de services Web est presente figure 3-10. Chaque brique 
technologique representee dans le diagramme joue un role precis dans une architecture orientee 
services. L architecture orientee services est done une specification « generique » d'une famille de 
systemes repartis dont les technologies de services Web constituent un moyen d'implementation 
privilegie. 

Les fondations technologiques des services Web (voir le chapitres 5) sont les technologies Internet : 

• la notion d'URI (Uniform Resource Identifier) ; 

• 1' ensemble des protocoles Internet : IP, TCP, HTTP, SMTP, etc. 

Loutil technologique fondamental (la base) a la mise en ceuvre des technologies de services Web est 
XML, avec ses outils de support comme XML Schema, XML Namespaces, etc. 

La pile des technologies de services Web commence a proprement parler avec les protocoles 
d'echange. Ces protocoles imposent tous un format de message XML. Le message, accompagne 
eventuellement de pieces jointes, est transmis sur un protocole de transport Internet. 

SOAP est le protocole d'echange le plus repandu, mais il faut preciser qu'il n'est pas un element 
impose dans une architecture de services Web. D'autres protocoles, comme XML-RPC ou la simple 
inclusion de documents XML dans les corps des requetes et des reponses HTTP sont consideres 
comme des technologies de services Web a pail entiere. 

Au niveau description, WSDL (Web Services Description Language) est le langage de description 
des services Web, meme s'il n'est pas formellement impose par l'architecture de reference du W3C. 
On peut considerer aujourd'hui qu'une description WSDL est necessaire pour qu'une application 
puisse revendiquer la qualification de service Web. 

Des services Web fonctionnent aujourd'hui par l'utilisation directe de HTTP en tant que protocole de 
transport et de documents XML en tant que conteneurs de donnees ayant un format mutuellement 
accepte par les participants de l'echange. 

En revanche, l'architecture de reference des services Web fait explicitement l'hypothese que les 
niveaux plus eleves de la « pile » de technologies de services Web se basent sur SOAP et WSDL 
(Web Services Architecture, W3C Working Draft 14 November 2002). Cela veut dire que les services 
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Figure 3-10 

Le diagrcimme des technologies de services Web. 



Web qui ne sont pas mis en ceuvre avec WSDL sur SOAP ne pourront pas beneficier des technologies 
evoluees d' infrastructure (fiabilite des echanges, gestion de la securite, gestion des transactions, 
gestion des processus metier) aujourd'hui en developpement. 

Les prestataires des services Web, leurs interfaces et leurs points d'acces, peuvent etre enregistres, 
decouverts et localises via des technologies d'annuaire comme UDDI (Universal Description, Disco- 
very and Integration of Web Services). Autant un standard ouvert (non-proprietaire) sur les annuaires 
de services Web semble indispensable, surtout pour la mise en ceuvre d' architectures dynamiques, 
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autant la technologie UDDI, qui est clairement une technologie de services Web, n'est pas (encore ?) 
formellement consideree aujourd'hui comme le standard des annuaires. 

WSDL, SOAP et UDDI constituent F ensemble des technologies cles de services Web, sur lequel 
d'autres technologies plus proches de la problematique applicative peuvent etre specifiees et mises en 
ceuvre. A l'heure de la redaction de cet ouvrage, ces technologies cles sont stables et leur evolution 
ralentit, tandis que d'autres technologies s'attaquent a la resolution de problemes specifiques 
d' infrastructure : les plus importants sont en gestation et concernent la fiabilite des echanges, la secu- 
rite et la gestion des transactions. Sur des problematiques plus applicatives, comme la coordination 
des applications reparties pour la mise en ceuvre de processus metier, nous sommes encore dans la 
phase ou plusieurs propositions s'affrontent. 

Les organisations impliquees 

Les organisations impliquees aujourd'hui dans la definition, la verification et la validation des 
normes et standards des technologies de services Web sont : 

• World Wide Web Consortium (W3C), via son « activite » Web Service Activity (http://www.w3.org/ 
2002/ws/Web Services); 

• Web Services Interoperability Organization (ou WS-I, http://www.ws-i.org); 

• Organization for the Advancement of Structured Information Standards (ou OASIS, http://oasis- 
open.org). 

W3C Web Service Activity 

II est superflu de presenter le W3C. L' activite Web Services du W3C a ete formalisee en Janvier 2002 
comme une activite de normalisation des technologies de base de services Web (l'echange et la 
description). C'est le cadre que les initiateurs de la vague des services Web (nee a l'exterieur du W3C) 
ont voulu donner a la poursuite et finalisation des travaux de normalisation et de standardisation des 
technologies. 

L' activite Web Services est organisee en trois groupes de travail (Working Groups ou WG) : 

• Architecture WG, qui a comme tache de definir 1' architecture generale des services Web ; 

• XML Protocol WG, qui a en charge les protocoles d'echange et notamment la version 1.2 de 
SOAP; 

• Web Services Description WG, qui a en charge le langage de description des interfaces et des 
liaisons et notamment la version 1.2 de WSDL (Web Services Description Language). 

Web Services Interoperability 

WS-I est un consortium cree en Janvier 2002. Lobjectif de son activite est la verification et la validation 
de l'interoperabilite reelle des implementations des technologies de services Web developpees par les 
editeurs du marche (qui sont membres de l'organisation). Pour ce faire, WS-I est organisee en trois 
groupes de travail (Working Groups ou WG) : 

• WSBasic Profile WG : la tache du groupe est de definir la notion de « profil », qui est un ensemble de 
technologies ayant un niveau de version, qui sont susceptibles de constituer un ensemble coherent, 
operationnel et interoperable. WS-I a defini le profil basique qui est constitue de WSDL 1.1, SOAP 1 . 1 
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et UDDI 2.0 (voir figure 3-11). Ce groupe de travail vient de publier en date 8 octobre 2002 le Basic 
Profile Version 1.0 - Working Group Draft (http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0- 
WGD.htm) avec cent recommandations pour Finteroperabilite. 

WSBasic Sample Applications and Scenarios WG : la tache du groupe de travail est de definir et 
d'instrumenter des applications temoins et des scenarios d' utilisation des technologies du profil 
basique. 

WS-Testing WG : la tache du groupe de travail est de definir des outils et des methodologies de test 
d'interoperabilite. 



Figure 3-11 

Le profil basique 
des technologies de 
services Web. 




OASIS 

OASIS est une organisation internationale qui comprend une presence majoritaire d'utilisateurs. Elle 
est active depuis plusieurs annees dans le domaine de la normalisation en SGML, et ensuite en XML 
au niveau metier. 

Lactivite ebXML (electronic business XML), conduite en partenariat avec FONU (EDIFACT), a 
comme cible Fechange de donnees informatisees (EDI) sur la base du format XML. 

Lobjectif de ebXML est de formaliser les processus metier interentreprises (B2B). II s'agit de 
formaliser les processus d'interactions, les formats et la semantique des documents echanges (de type 
commande, facture, etc.), les profils des participants a Fechange, ainsi que les accords entre participants 
pour la mise en ceuvre de Fechange. ebXML a par ailleurs formalise F infrastructure technique qui 
rend possible Fechange (un service de messagerie et un annuaire/referentiel de documents). 

OASIS ebXML a produit, en complement des documents de requirements, d' architecture generate et 
de glossaire, quatre specifications : 

• ebXML Business Process Specification Schema (http://www.ebxml.org/specs/ebBPSS.pdf) ; 
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• ebXML Collaboration Protocol Profile and Agreement Specification (http://www.oasis-open.org/ 
committees/ebxml-cppa/documents/ebcpp-2. 0.pdf) ; 

• ebXML Registry Services Specification (http://www.ebxml.org/specs/ebrs2.pdf) ; 

• ebXML Message Service Specification (http://www.ebxml.org/specs/ebMS2.pdf). 

ebXML prend en compte aujourd'hui dans ses travaux de normalisation les technologies d'echange 
et de description de services Web (SOAP, WSDL). Les principaux promoteurs des technologies de 
services Web lui confient aujourd'hui les processus de normalisation des briques technologiques de 
niveau plus « eleve » comme Fannuaire UDDI (niveau decouverte), ainsi que les briques « trans versales » 
comme la securite (WS-Security) et la gestion des transactions (BTP). 

La convergence en cours entre les technologies de services Web et les technologies ebXML nous permet 
de presenter aujourd'hui les relations entre ces deux axes de normalisation de la facon suivante : 

• L'axe services Web, pousse par les industriels (IBM, Microsoft, etc.), a mis en ceuvre une demarche 
bottom-up : des technologies de base (SOAP, WSDL) via les technologies d' infrastructure (UDDI, 
la fiabilite des echanges, la gestion de la securite, la gestion des transactions), vers le niveau 
applicatif (gestion des processus metier, etc.). 

• L'axe OASIS ebXML, avec une participation forte des utilisateurs, a mis en ceuvre une demarche 
top-down : de la definition des processus electronic business (BPS), en passant par la definition des 
contrats (CPP/CPA), vers les technologies de mise en ceuvre (le service d'annuaire et de referentiel, 
le service de messagerie). 

La presentation ci-dessus est sommaire mais n'est pas eloignee de la realite. ebXML a eu le merite de 
poser un certain nombre de questions qui trouveront sans doute des reponses dans le developpement 
des technologies de services Web. Dans ce developpement, OASIS va jouer un role tres important. 

Aujourd'hui, OASIS est en charge de plusieurs chantiers (Technical Committees) de normalisation de 
technologies de services Web : 

OASIS UDDI Specification TC ; 

XML-Based Security Services TC (SSTC), Security Assertion Markup Language ; 

OASIS Web Services Security TC ; 

OASIS Business Transaction TC ; 

OASIS Web Services for Interactive Applications TC ; 

OASIS Web Services for Remote Portals (WSRP) TC. 

Les technologies de services Web dans la mise en ceuvre des architectures 
orientees services 

La cible des technologies de services Web est bien les architectures orientees services. Un service 
Web est naturellement une application orientee services (une application participante d'une architec- 
ture orientee services). En revanche, une application orientee services n'est pas forcement un service 
Web car la definition du W3C met en jeu des contraintes sur quatre technologies cles : 

• les technologies A' identification des applications ; 

• les technologies de description, propres aux langages de description des interfaces et des liaisons ; 
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• les technologies de message, propres aux formats des messages et aux protocoles d'echange ; 

• les technologies de transport, propres aux protocoles de transport impliques dans les echanges. 

Ces quatre technologies forment \e profil technologique d'une application par rapport a la definition 
de service Web. Selon la definition du W3C, une application orientee services peut etre qualifiee de 
service Web si elle exhibe le profil technologique suivant, presente par le diagramme dans la figure 3-12 : 

• Identification : le service Web est identifie par un URI. 

• Description : les interfaces et les liaisons d'un service Web sont decrites (et done peuvent etre 
definies et decouvertes) au moyen d'un langage XML. 

• Message : un service Web communique avec les autres agents logiciels au moyen de messages au 
format XML. 

• Transport : les messages sont transmis via des protocoles Internet. 



Figure 3-12 

Profil technologique 
general d'un service Web. 
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Un service Web qui s'appuie sur les standards WSDL et SOAP (liaison HTTP) presente le profil 
technologique illustre par le diagramme de la figure 3-13. 



Figure 3-13 

Profil technologique 
d'un service Web 
s 'appuyant sur WSDL 
et SOAP (liaison HTTP). 
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Plus specifiquement, le profil basique WS-I (nous ne prenons pas en consideration dans ce contexte 
le niveau decouverte UDDI 2.0) est illustre par le diagramme de la figure 3-14. 
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Figure 3-14 

Un service Web « basic 
profile » WS-I. 
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L' application ail profil technologique illustre par le diagramme de la figure 3-15 est un service Web, 
meme s'il ne s'appuie pas sur SOAP (il communique via des documents XML au format libre dans le 
corps de messages HTTP GET/POST). 



Figure 3-15 

Profil technologique 
d'un service Web 
utilisant la liaison HTTP 
GET/POST. 
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Par ailleurs, une application ayant ses interfaces et liaisons decrites en WSDL peut utiliser un format 
de message SOAP sur un protocole de transport proprietaire comme IBM MQSeries (protocole asyn- 
chrone et fiable, base sur un systeme de files de messages). L' identification de l'application peut etre 
effectuee soit selon la convention URI, soit par d'autres systemes d' identification. La definition de 
service Web ne permet pas de qualifier cette application comme un service Web (voir figure 3-16). 



Figure 3-16 

Profil technologique d' une 
application s 'appuyant sur 
un protocole de transport 
proprietaire. 



Identification 


URI ou autre ID 


Description 


WSDL 


Message 


SOAP 


Transport 


IBM MQSeries 



L'architecture orientee services 

Premiere Partie 



Une variante est obtenue par l'utilisation de JMS (Java Messaging System) comme systeme de 
messagerie. II s'agit d'un protocole de messages qui peut etre considere comme standard mais qui est 
dependant du langage (Java) utilise, et qui s'impose a Femetteur comme au recepteur. II met en 
ceuvre un systeme de messagerie asynchrone entre applications Java distantes, par l'utilisation du 
protocole RMI (Remote Method Invocation). IBM propose une mise en ceuvre de JMS sur MQSeries 
(figure 3-17). 



Figure 3-17 

Profit d'une application 
qui utilise un systeme 
de messagerie dependant 
du langage sur un 
protocole proprietaire. 
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Une approche equivalente dans le monde Microsoft, representee dans le diagramme figure 3-18, 
met en ceuvre des technologies de description et d'echange de services Web sur un protocole de 
transport proprietaire, ce qui limite Finteroperabilite aux applications mises en ceuvre sur Fenviron- 
nement MS .NET. 



Figure 3-18 

Une application qui 
s 'appuie sur le protocole 
de transport proprietaire 
Net Remoting. 
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Pour conclure, le diagramme de la figure 3-19 presente une application batie sur des technologies 
issues du monde des standards ouverts (CORBA ou Common Object Request Broker Architecture), 
mais qui ne peut pas etre qualifiee de service Web. A noter que le protocole de transport HOP (Inter- 
net Inter-ORB Protocol) est un protocole standard Internet, adopte par 1TETF, et qui permet done 
theoriquement le deploiement sur Internet. 

La description de Finterface utilise 1'IDL (Interface Definition Language) et Fobjet cible de Finvocation 
de methode est identifie via un IOR (Interoperable Object Reference). Le message utilise le standard 
GIOP (General Inter-ORB Protocol) sur HOP, qui est la mise en ceuvre des messages GIOP sur TCP/IP. 
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Le contenu des messages (les donnees) est encode en respectant le format CDR (Common Data 
Representation). 

Figure 3-19 

Une application en 
technologie CORBA 2.0 
(OMG). 
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Specifications d'interface et contrats types 

Dans la mise en place des architectures de services Web aujourd'hui, la fonction de contrat est essen- 
tiellement portee par le document WSDL. Un document WSDL permet de definir F implementation 
de l'interface, a savoir : 

• les styles d'echange ; 

• les formats des messages ; 

• les conventions de codage ; 

• les protocoles de transport ; 

• les ports de reception. 

Les clauses listees ci-dessus sont suffisantes pour instrumenter le contrat entre le client et le prestataire, 
et done pour garantir l'interoperabilite. La definition d'un contrat limite a ces articles et clauses a 
l'avantage de la simplicite. Mais il a l'inconvenient de delaisser beaucoup de themes assez pertinents 
d'un point de vue contractuel. WSDL prevoit un mecanisme standard d' extension qui sera sans doute 
de plus en plus utilise pour traiter au moins une partie de ces themes : 

• la description des fonctions du service (au niveau fonctionnel) ; 

• la description de l'interface abstraite (notamment le lien entre les actes de communication et les 
fonctions du service) ; 

• la description de la qualite du service. 

La description des fonctions et de l'interface abstraite du service 

L'effort de conception et de redaction des specifications fonctionnelles d'un service Web est tres 
important, et parfois hors de la portee des organisations qui participent a la mise en place d'architec- 
tures orientees services. Les redacteurs ne doivent pas oublier que leurs specifications doivent 
pouvoir etre exploiters par des acteurs humains qui, dans le cas le plus general, ne font pas partie de 
leur organisation, n'ont pas la meme culture et ne parlent pas la meme langue. Cette exigence impose 
un niveau tres eleve de qualite et de standardisation de ces specifications. 
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La difficulte a etablir au cas par cas les specifications fonctionnelles est un vecteur puissant de mise 
en place de normes et standards (contrats types) par secteurs metier. Des organisations professionnelles 
et des organismes de normalisation vont mutualiser la conception et la redaction des specifications de 
services standards pour les differents metiers. 

Ces specifications fonctionnelles, couplees aux specifications d' interface, vont permettre une reelle 
interoperabilite au niveau metier (au-dela du niveau technique) entre applications. Les applications 
vont non seulement s'echanger des messages, mais aussi se comprendre. 

Un contrat ainsi etabli est un contrat type. Le contrat type renvoie explicitement ou implicitement aux 
specifications fonctionnelles du service. 

La mise en ceuvre d'une occurrence d'un service type de la pail d'un prestataire se reduit done a la 
designation de la reference au contrat type et des points d'acces. Lannuaire UDDI est particulierement 
adapte a cet usage. 

La description de la qualite de service 

La description de la qualite de service ne presente pas la difficulte de formulation propre aux 
specifications fonctionnelles. 

On peut pre voir Fessor de langages specialises (extensions de WSDL ou autre) pour definir les differents 
aspects de la qualite de service. Le travail est deja bien entame sur deux sujets essentiels comme la 
securite et la gestion des transactions. Comme pour SOAP et WSDL, la specification des protocoles 
precede necessairement la specification du langage de description. Dans la road map de WS-Security, 
le langage de definition des contraintes de securite WS-Policy est en voie de normalisation. 

La mise en ceuvre et V utilisation d'un langage de description de la qualite de service, prenant en 
compte les autres aspects de la qualite (le dimensionnement, la performance, la fiabilite, la disponibilite, 
l'exactitude et la precision, etc.), et interpretable par programme, va changer en profondeur la facon 
de concevoir, de realiser et d' exploiter les services et les applications. Les contrats types peuvent 
prevoir des niveaux minimaux de qualite de service, au-dessous desquels le contrat n'est pas 
respecte, et les niveaux plus eleves peuvent faire Fobjet d' accords particuliers, d'offres plus evoluees, 
et constituer Favantage competitif d'un prestataire. 

Dans ce chapitre, nous avons complete la presentation des articles du contrat de service, rappele les 
differents usages du contrat et etabli un etat des lieux des technologies de services Web en relation 
avec la mise en place d' architectures orientees services. Dans le prochain chapitre nous allons evoquer 
les demarches de mise en ceuvre des architectures orientees services et presenter les differents modeles 
d' architecture a configuration dynamique. 
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Construire une architecture orientee services signifie d'abord concevoir une architecture en reseau de 
relations de service, regentees par des contrats, entre applications reparties. 

La construction de F architecture est un processus qui implique differentes activites : 

• la definition de contrats de service et la mise en place des interfaces pour les applications 
patrimoniales ; 

• la conception de nouveaux services, la definition de leurs contrats et la mise en ceuvre des applications 
prestataires ; 

• revolution des applications patrimoniales et la conception de nouvelles applications capables de 
tirer parti des nouveaux services disponibles. 

Dans ce chapitre, nous ne faisons pas de distinction entre le deploiement de ces architectures en 
intranet ou sur Internet. Cette distinction a un impact sur les fonctions offertes, sur la structure des 
droits et des habilitations et sur les moyens pour assurer la securite, mais n'est pas vraiment perti- 
nente dans le contexte de la discussion qui suit. En outre, la montee en puissance du concept et de la 
pratique de l'entreprise etendue (a ses partenaires, clients, fournisseurs) et les nouveaux besoins 
d' interaction des administrations avec les citoyens et les entreprises rendent obsolete la distinction 
rigide intranet/Internet. 

Conception d'architectures orientees services 

Une architecture orientee services peut etre concue par une approche incrementale, resultat de la 
combinaison de deux demarches de base : 

• Yagregation de services ; 

• la dissemination de services. 
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L'approche par agregation de services 

Nous allons presenter 1' agregation de services a travers un exemple, illustre figure 4-1. 

Pour Fagence de voyage Our Travels, qui travaille pour des entreprises de dimension internationale, 
le marche des voyages d'affaires est une composante essentielle de son chiffre d'affaires. Par ailleurs, 
ses entreprises clientes se dotent de plus en plus d' applications de gestion des missions des collabo- 
rateurs, integrees dans leur systeme de gestion des frais et des achats. Our Travels constate cette 
tendance et decide de reflechir a la constitution d'une offre appropriee de services en ligne. 

Un voyage d'affaires est systematiquement constitue de trois elements, dont certains evidemment 
optionnels : 

• une reservation aerienne ; 

• une reservation de chambre d' hotel ; 

• une reservation de voiture. 

Les fournisseurs habituels d'Our Travels sont : 

• la compagnie aerienne My Airways, qui dessert un nombre important de destinations pour ses 
clients ; 

• la chaine hoteliere Your Resort, dont les etablissements sont presents dans ces destinations ; 

• l'entreprise de location de voitures Her Car Rental, elle aussi presente dans ces destinations. 

Ces fournisseurs ont choisi de se mettre a l'heure des services Web et proposent des services en ligne 
directement accessibles aux applications de leurs clients. La direction d'Our Travels decide de 
constituer un service en ligne de support d'une offre integree « Organisation de voyages d'affaires », 
adaptee aux besoins de ses clients, sur la base d'une architecture orientee services. L'idee est que les 
applications de gestion de missions des entreprises clientes puissent acceder directement a un service 
d' organisation de voyages d'affaires. 

La direction d'Our Travels confie la conception et le developpement de cette nouvelle offre a une 
equipe mixte, composee d'experts metier et d'informaticiens. Les premieres taches du projet sont : 

• la conception et la redaction d'un brouillon d'un contrat de service « Organisation de voyages 
d'affaires » pour les applications des entreprises clientes ; 

• 1' etude et 1' experimentation des services proposes par les fournisseurs, de leurs contrats de service 
et du fonctionnement concret des services en ligne existants : dans certains cas, une validation de 
la performance, au sens large, du service et de sa conformite au contrat est necessaire (il s'agit de 
services qui ont ete mis en place recemment). 

Ces deux taches sont conduites en parallele, avec des points de synchronisation frequents. Elles 
relevent de deux approches symetriques : 

• Approche outside-in : cette approche consiste a etablir le contrat de service « Organisation de 
voyages d'affaires » a partir du besoin du marche, sans tenir compte a priori des offres de services 
necessaires a sa mise en ceuvre. L'approche outside-in peut etre conduite en utilisant des moyens 
importants comme un large recueil des besoins des clients potentiels et de leurs applications 
d'entreprise. L'avantage est que le contrat de service est construit a partir du besoin du marche. 
L inconvenient est que les services des prestataires dont Our Travels a besoin peuvent se reveler 
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inadaptes a la mise en ceuvre d'un service correspondant au contrat. L'avantage de cette approche 
est la pertinence, le risque en est la faisabilite. 

Approche inside-out : cette approche consiste a etudier en detail et de facon experimental les 
offres de services necessaires a la mise en ceuvre de l'offre « Organisation de voyages d'affaires », 
apres en avoir etabli les principes generaux. Le service agrege est construit experimentalement par 
prototypage et le contrat de service est une documentation du resultat. L'avantage de cette 
demarche est que Ton arrive rapidement au developpement d'un prototype et a l'etablissement 
d'un contrat de service qui n'est qu'une description a posteriori des fonctions du prototype realise. 
L inconvenient est que le service et le contrat peuvent ne pas correspondre au besoin du marche. 
L'avantage de cette approche est la faisabilite, le risque en est la pertinence. 

La demarche inside-out est obligatoire lorsque les services des prestataires ne sont pas suffisam- 
ment murs, leurs contrats incomplets et que le comportement a F execution presente des non- 
conform! tes. 
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Figure 4-1 

Agregation de sendees. 



II est generalement conseille de suivre la methode d'Our Travels, e'est-a-dire d'entamer et de pour- 
suivre les deux approches en parallele, avec des echanges intenses et continus entre les deux equipes. 
Ces echanges sont indispensables pour que les deux approches puissent converger le plus rapidement 
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possible vers un compromis, a savoir un contrat pour un service pertinent et faisable. Conduire 
en parallele les approches outside-in et inside-out permet en outre de raccourcir les delais de mise en 
oeuvre, car le modele d' implementation est fait en meme temps que le modele fonctionnel du service, 
sans pour autant rompre la relation de dependance entre les deux modeles qui dicte que le modele 
fonctionnel est une specification pour le modele d' implementation. 

La relation entre les contrats de service (le contrat de service « Organisation de voyages d'affaires » 
et les contrats de service des fournisseurs d' Our Travels) sont en fait complexes et la double approche 
esquissee est indispensable pour maitriser cette complexite. La richesse fonctionnelle et le niveau de 
qualite du service « Organisation de voyages d'affaires » sont en fait dependants : 

• d'un cote, de la richesse fonctionnelle et du niveau de qualite des services des fournisseurs ; 

• de 1' autre cote, de la valeur ajoutee d'Our Travels, a savoir de l'« intelligence » des regies de 
gestion, de recherche et de combinaison mises en ceuvre par 1' application. 

L'architecture d'agregation de services qu'Our Travels met en ceuvre pour la premiere version de son 
service d' organisation de voyages d'affaires est statique : les services, mais aussi les prestataires sont 
connus a l'avance. Pour la deuxieme version, Our Travels prend acte que plusieurs de ses fournis- 
seurs habituels ainsi que d'autres nouveaux acteurs du marche offrent desormais des services Web 
comparables a ceux offerts respectivement par My Airways, Your Resort et Her Car Rental. Certains 
d'entre eux, membres d'organisations professionnelles et d'organismes de normalisation, proposent 
meme des contrats types qui, pour certaines parties (fonctions, interfaces et/ou exigences de qualite), 
sont normalises par ces organismes et ces organisations professionnelles. 

La deuxieme version du service d' organisation de voyages d'affaires est beaucoup plus sophistiquee 
que la premiere. Sur la base de la requete de 1' application cliente, 1' application d'Our Travels choisit 
a V execution la combinaison optimale de fournisseurs, sur la base : 

• des preferences exprimees par le client ; 

• des regies de gestion de l'entreprise, dont 1' application est eventuellement dependante de son 
contexte economique (maximiser la marge de l'entreprise, maximiser la satisfaction du client, 
etc.) ; 

• de la situation reelle (les places disponibles, par exemple) ; 

• du contexte technique d'execution (comme les serveurs en service et accessibles). 

L application est maintenant beaucoup plus complexe et demande plus d' effort en parametrage, pilotage, 
maintenance et evolution, mais sa valeur ajoutee pour Our Travels et ses clients est indiscutable et 
concretement mesurable 

L'approche par dissemination de services 

Nous allons presenter la dissemination de services par un exemple, illustre figure 4-2. 

Une grande entreprise transnationale du secteur de l'industrie culturelle et des services en ligne, 
Little Brother Inc., a deploye une application integree de gestion RZO, qui est utilisee par une grande 
partie du personnel, reparti en plusieurs departements. Par la mise en place d'un systeme de gestion 
des profils, chaque utilisateur percoit une vue de 1' application correspondant a son profil. 
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D'autres applications, liees a des activites plus operationnelles du metier de l'entreprise, ont besoin 
d'acceder aux donnees et aux traitements geres par RZO. Cet acces a ete realise dans le passe par des 
procedures lourdes, peu performantes et difficiles a exploiter et a maintenir, comme des replications 
partielles de la base de donnees RZO executees par des traitements asynchrones d' export/import, et 
la duplication des regies de gestion dans les applications metier. Les applications metier de Little 
Brother pourraient gagner en performance et en cout de maintenance en accedant directement aux 
donnees et aux traitements mis en ceuvre par RZO. Le probleme de Finteroperabihte entre applications 
metier et RZO est pose. 

La direction de Little Brother decide de demarrer un programme d' urbanisation du systeme d'infor- 
mation de l'entreprise, base sur la mise en ceuvre d'une architecture orientee services. L'interoperabilite 
avec F application RZO, au cceur de la gestion de Fentreprise, est un des premiers objectifs du 
programme. II serait evidemment facheux que les exigences d'interoperabilite imposent la refonte 
complete de F application RZO : fort heureusement, les technologies et les outils de services Web 
permettent de batir rapidement la « glu » necessaire a Faeces, de la part des autres applications, aux 
traitements et aux donnees geres par RZO, sans modification de F application RZO elle-meme. 
Encore faut-il definir les fonctions que Fon veut exposer comme des services et F interface par 
laquelle on souhaite les rendre accessibles. En effet, il existe deja une interface programmatique aux 
serveurs RZO, utilisee dans le but de recuperer les informations et d'invoquer les traitements neces- 
saires pour afficher les ecrans et traiter les formulaires de saisie de Finterface homme/machine de 
RZO. La direction donne comme consigne de reutiliser au maximum Finterface programmatique 
existante et de limiter son evolution au strict necessaire. 

Le perimetre de F application RZO est tres vaste et couvre F ensemble des fonctions de gestion de 
Fentreprise. C'est bien le resultat d'une strategie volontariste de centralisation de toutes les fonctions 
de gestion dans une seule application, developpee dans le cadre d'un grand projet qui s'est deroule 
sur plusieurs annees. L'integration presente des avantages, mais aussi des inconvenients lorsque Fon 
veut utiliser seulement une partie des donnees et des traitements geres par RZO. La difficulte n'est 
pas seulement technique, elle est egalement conceptuelle : le concepteur de F application cliente de 
RZO doit s'approprier et maitriser une partie importante de la complexite de F application, y compris 
pour reutiliser une petite partie de ses donnees et de ses traitements. 

La direction de RZO decide de demarrer la collecte des besoins des applications clientes. Une equipe 
de specialistes de F application RZO et d' experts de la mise en place d' architectures orientees services 
est constitute. II s'agit d'un cote de recenser les besoins en donnees et traitements, et de Fautre de 
valider leur implementation en termes de fonctions et d'interfaces RZO disponibles. 

Comme dans la demarche d'agregation des services, deux approches symetriques sont possibles : 

• Approche outside-in : cette approche consiste a etablir les contrats de service a partir du besoin des 
applications clientes potentielles, sans tenir compte a priori de l'offre des services RZO neces- 
saires a sa mise en ceuvre. L'avantage est que les contrats des services modulaires sont construits a 
partir du besoin du « marche interne ». L inconvenient est que les services modulaires ainsi concus 
peuvent se reveler difriciles a mettre en ceuvre, insuffisamment pris en charges par RZO et redondants. 
L'avantage de cette approche est la pertinence, F inconvenient reside dans la faisabilite. 

• Approche inside-out : cette approche consiste a etudier en detail et de facon experimental les 
possibilites de developper des services modulaires a partir de RZO. L'avantage de cette 
demarche est que Fon arrive rapidement a la mise en ceuvre d'un ensemble de services modulaires. 
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L' inconvenient est que ces services peuvent se reveler peu maniables et les contrats resultants 
peuvent ne pas correspondre au besoin du marche interne. L'avantage de cette approche est la 
faisabilite, la faiblesse possible en est la pertinence. 

Comme dans la demarche de Fagregation, il est conseille d'entamer et de poursuivre les deux approches 
en parallele, avec des echanges intenses et continus entre les deux equipes. Le resultat sera un 
compromis : la constitution, a partir de l'ensemble des traitements et des API RZO, de services 
metier coherents, de taille et de complexite maitrisables, utiles a d'autres applications. L'idee est que 
chaque service est autosuffisant : on peut le comprendre et Futiliser en ignorant les autres. Pour 
atteindre cet objectif, un certain degre de superposition fonctionnelle entre services est tolere. 

La phase de definition des services se termine avec 1' identification des cinq services metier listes 
figure 4-2 a partir des besoins de six applications metier clientes potentielles et des fonctions et 
interfaces deja proposees par RZO. 
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Figure 4-2 

Dissemination de services. 
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Une fois les services identifies, l'equipe de specialistes entame une etape de definition et de redaction 
des contrats. Cette etape est importante, mais ne presente pas de dirficultes majeures, car le modele 
fonctionnel du contrat de service est un modele descriptif, en grande partie une documentation des 
fonctions existantes. Par ailleurs, les fonctions et les interfaces du service ne sont pas necessairement 
isomorphes aux fonctions et interfaces correspondantes de RZO. Un service a valeur ajoute peut 
encadrer les invocations a RZO par des pretraitements et/ou post-traitements, combiner plusieurs 
invocations a RZO en une seule requete, et done exposer a ses clients des fonctions plus sophistiquees 
et/ou une interface plus simple et homogene. Ce service peut egalement gerer des sessions de travail 
ou eventuellement des transactions, si RZO est en mesure de proposer un protocole de confirmation. 
Cette phase s'accompagne d'un prototypage d'au moins deux de ces services et des evolutions des 
applications clientes, necessaires a l'utilisation des services. 

Lorsque les contrats des services sont approuves par les responsables des applications clientes, la phase 
d' implementation industrielle peut passer a la vitesse superieure et se conclure avec le developpement 
des services specialises RZO et revolution des applications clientes. Les services specialises RZO 
peuvent etre mis en ceuvre comme des frontaux qui agissent en intermediaries entre les applications 
clientes et RZO. 

En conclusion, un des premiers objectifs du programme d' urbanisation du systeme d'information 
promu par la direction de Little Brother, a savoir V interoperability entre applications, a ete atteint. En 
plus, cette interoperabilite a ete obtenue par un couplage faible des applications d'entreprise : 

• non seulement en termes techniques : chaque application cliente n'a aucune « connaissance » de 
F implementation de RZO, et vice-versa (les technologies de services Web utilises sont totalement 
non intrusives) ; 

• mais aussi en termes fonctionnels : chaque application metier est cliente d'au plus deux services 
RZO. De meme, l'exploitation des donnees et des traitements RZO de la part des applications 
clientes demande, de la part du concepteur, la connaissance de ces deux services seulement. 

Par ailleurs, un effet induit par la mise en place de services modulaires est que maintenant revolution 
et eventuellement la refonte de RZO peuvent etre planifiees avec une demarche incrementale. Certaines 
parties de RZO peuvent etre remplacees par de nouveaux composants logiciels, sans qu'il soit necessaire 
de modifier les applications clientes : 1' implementation change, l'interface reste la meme. 

Ce scenario est approprie lorsque F application de gestion integree RZO est une application patrimoniale 
de Little Brother. On peut imaginer un scenario different. Big Sister Ltd, une compagnie transnationale 
concurrente de Little Brother, au lieu de developper par ses propres moyens une application de 
gestion integree, a choisi d' installer et de parameter le progiciel de gestion integree TBQ. TBQ 
Gmbh, qui commercialise le progiciel eponyme, a prevu le besoin de ses clients et a developpe un 
certain nombre d'interfaces, baties sur les technologies de services Web, qui mettent a disposition des 
applications clientes un certain nombre de fonctions TBQ, commercialises comme des add-on. Ces 
interfaces ne presentent peut etre pas une adherence parfaite aux besoins des applications metier 
clientes de Big Sister (le progiciel TBQ lui-meme, par ailleurs, n'offre pas non plus cette adherence 
parfaite), mais ils ont le merite d'exister et de trancher d'emblee une partie des discussions, qui 
risqueraient sans cela de se prolonger, sur les « meilleurs » services a specifier et a mettre en ceuvre. 

Les architectures orientees services et les technologies de services Web ouvrent de nouvelles 
perspectives aux editeurs de progiciels et a leurs utilisateurs. Pour les editeurs, elles ouvrent des 
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nouveaux marches avec des efforts limites en recherche et developpement (developpement de la 
« glu » autour du progiciel lui-meme). Pour les entreprises utilisatrices, elles ouvrent la voie du 
desenclavement et de l'urbanisation des systemes d' information. 

Combinaison des approches 

Lagregation et la dissemination des services constituent des approches de base de conception et de 
mise en ceuvre d' architectures orientees services. Les architectures orientees services complexe qui 
vont se deployer dans les annees a venir seront sans doute le resultat de la combinaison de ces deux 
approches. 

II est important d'insister sur le caractere incremental et etale dans le temps de telles demarches. Le 
modele de l'architecture orientee services se prete parfaitement a V urbanisation des systemes 
d'information au sens large (intra et interentreprises), il permet ainsi de planifier dans le temps et 
dans l'espace la reutilisation et la fin de vie des applications existantes, la refonte des applications, la 
mise en ceuvre de nouvelles applications a valeur ajoutee, tout en garantissant leur interoperabilite. 

Les architectures orientees services dynamiques 

Une architecture d' applications reparties faiblement couplees (ou architecture faiblement couplee) 
est constitute d'un ensemble decentralise d' applications reparties autonomes, lesquelles inter- 
agissent sur la base de protocoles de communication asynchrones, et sont mises en ceuvre a l'aide de 
technologies ouvertes et non intrusives. 

Une architecture repartie est dite decentralisee lorsque F ensemble des applications constituantes 
n'est pas dote d'une autorite centrale de surveillance, de controle et de gestion. 

Une application participant a une architecture repartie est dite autonome lorsqu'elle exhibe les 
caracteristiques suivantes : 

• son implementation est independante des specificites de la mise en ceuvre des autres applications de 
1' ensemble (1' architecture logicielle, le langage d' implementation, le systeme d' exploitation, la 
technologie des bases de donnees), sauf pour la mise en ceuvre des interfaces de communication 
avec les autres applications de l'ensemble ; 

• sa participation a l'architecture n'impose pas de choix technologique sur F implementation des 
autres applications de l'ensemble, sauf pour la mise en ceuvre des interfaces de communication ; 

• sa defaillance ou la defaillance de F infrastructure de communication avec les autres applications influe 
naturellement sur Factivite des autres applications, mais n'induit pas directement leur defaillance : 
sa possibilite peut et doit etre prise en compte dans le comportement normal des autres applications ; 

• les defaillances des autres applications ou de F infrastructure de communication avec les autres 
applications influent evidemment sur le comportement de F application, mais ne provoquent pas sa 
defaillance : elles peuvent et doivent etre prises en compte dans son comportement normal. 

Les protocoles de communication entre applications constituantes d'une architecture faiblement 
couplee sont generalement asynchrones. Un protocole de communication est synchrone si, du point 
de vue de l'application, la correlation entre deux ou plusieurs messages n'est pas explicite, au moyen 
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d'identifiants de messages et de references a ces identifiants, mais geree implicitement par le protocole 
de transport sous-jacent. L'appel de procedure distante (RPC) est un protocole de communication 
synchrone : le retour de la procedure distante est directement correle par le protocole de transport 
sous-jacent a F invocation de la procedure (qui peut etre bloquante ou non bloquante pour le fil 
d'execution de l'application appelante). Une architecture faiblement couplee met en ceuvre la 
communication asynchrone entre applications constituantes. 

Les infrastructures et technologies de communication (formats, protocoles), au niveau fonctionnel et 
technique, entre applications d'une architecture faiblement couplee, sont : 

• conformes a des standards ouverts : non-proprietaires, librement disponibles et accessibles ; 

• non intrusives : non seulement les systemes participant a Fechange ne sont obliges en aucun cas de 
connaitre les choix de mise en ceuvre de leurs interlocuteurs, mais, en outre, aucune installation de 
technologie dependante de ces choix n'est demandee prealablement a la mise en ceuvre de la 
communication. 

Le relachement de tout ou partie des contraintes citees (decentralisation, autonomie, asynchronisme. . .) 
donne lieu a une augmentation du degre de couplage entre applications d'une architecture repartie. 

Une architecture d' applications reparties fortement couplees (ou architecture fortement couplee) est 
une architecture : 

• dans laquelle une application, eventuellement pilotee par - un acteur humain, exerce des fonctions 
centralisees de surveillance, monitorage, controle, gestion ; 

• qui est constituee d' applications fortement dependantes entre elles en termes applicatifs, techno- 
logiques, de gestion des defaillances ; 

• dans laquelle les applications constituantes communiquent via des protocoles synchrones, mis en 
ceuvre a Faide de technologies de communication proprietaries et intrusives. 



Une grande partie des architectures reparties installees dans les reseaux locaux des entreprises et des adminis- 
trations correspondent au modele d'architecture fortement couplee. 



Le degre de couplage des architectures reparties evolue sur un continuum qui va du tres fortement 
couple au tres faiblement couple. Le modele de F architecture orientee services permet de modeliser 
des architectures a n'importe quel degre de couplage. 

II y a une correlation evidente entre le degre de couplage d'une architecture repartie, le nombre 
d' applications constituantes et F infrastructure de communication. Des architectures constituees de 
dizaines, voire de centaines ou de milliers d' applications reparties sur Internet doivent inevitablement 
mettre en ceuvre un degre de couplage tres faible : c'est une condition necessaire de leur existence et 
de leur survie. 

Les avantages en termes de qualite de service, de configuration dynamique, de facilite de maintenance 
et devolution des architectures faiblement couplees sont evidents. En revanche, leur conception et 
leur mise en ceuvre sont beaucoup plus complexes que celles des architectures fortement couplees, 
surtout du fait que les caracteristiques operationnelles (performance, fiabilite, disponibilite, continuite 
de service, etc.) ne peuvent etre totalement gerees en temps reel ni par - des couches logicielles techniques 
ni par des acteurs humains, mais remontent inevitablement au niveau du traitement applicatif. 
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Niveau de configuration dynamique 

Une architecture repartie d' applications est dite dynamique (a configuration dynamique) lorsqu'elle 
n'est pas entierement configuree en phase de developpement ou de deploiement, mais qu'au moins 
certaines parties sont configurees a la volee et eventuellement reconfigurees a l'execution. 

L'architecture dynamique demande : 

• que les informations necessaires a la configuration dynamique apparaissent dans des documents, qui 
font office de controls, disponibles a l'execution ; 

• la participation a l'architecture & applications tierces et intennediaires qui gerent ces informations 
et contrats et sont capables de les mettre a disposition des autres applications ; 

• des protocoles de conversation entre applications qui leur permettent de negocier et de determiner a 
l'execution les valeurs d'un certain nombre de parametres necessaires a leur configuration dynamique, 
si elles ne sont pas disponibles dans les contrats. 

Le premier niveau de choix dynamique touche sax points d'acces (adresses de communication/ports 
de reception) des applications participantes de l'architecture. Un niveau plus eleve de configuration 
dynamique touche certaines caracteristiques de V implementation de V interface de communication 
(formats de messages, conventions d'encodage des donnees, protocoles de transport, etc.) qui 
peuvent etre determinees a l'execution dans une liste finie de variantes possibles. II se peut egalement 
que le choix de la procedure d' authentification reciproque entre applications soit effectue a l'execution. 
D' autres parametres de l'architecture (notamment ceux qui touchent au niveau de qualite de service, 
comme, par exemple des delais d'attente) peuvent etre negocies a l'execution, apres etablissement de 
la liaison entre applications. 

Lorsqu'un service est mis en ceuvre par plusieurs applications prestataires « concurrentes », le choix 
des applications constituantes de l'architecture dynamique (outre leurs points d'acces, F implementation 
de l'interface, etc.) peut etre determine a l'execution. Au-dela du choix des applications qui mettent 
en ceuvre le meme contrat, le choix du contrat a executer peut egalement etre determine a l'execution 
(et, en cascade, le choix de l'application, de 1' implementation de l'interface, des points d'acces, etc.). 

Relation entre degre de coupiage et niveau de configuration dynamique 

La relation entre degre de coupiage et niveau de configuration dynamique des architectures reparties 
n'est pas lineaire, mais il est evident qu'une architecture faiblement couplee peut atteindre des 
niveaux eleves de configuration dynamique avec un effort de conception et de developpement moindre 
que celui qui est necessaire pour atteindre le meme resultat dans le cadre d'une architecture fortement 
couplee. 

L'espace a deux dimensions (degre de coupiage, niveau de configuration dynamique) est represente a 
la figure 4-3. Les applications patrimoniales d'aujourd'hui presentent generalement un niveau de 
configuration dynamique tres faible et un degre de coupiage tres fort. L'emergence des technologies 
de services Web est censee apporter un niveau d'interoperabilite tres eleve avec un degre de coupiage 
tres faible et done etablir les fondations des architectures reparties a haut niveau de configuration 
dynamique. 
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En fait, une grande partie des problemes d'integration disparaissent avec l'approche de F architecture 
orientee services et les technologies de services Web. Le terme meme d'integration est inadapte a 
propos des architectures orientees services et de leur implementation en services Web, et peut etre 
remplace par le terme d' interaction. Les applications qui composent une architecture orientee services 
dynamique ne sont pas « integrees », mais interagissent entre elles - de facon non predeterminee 
dans le cas le plus general - selon des modes, protocoles et interfaces repertories dans le contrat de 
maniere explicite. 




Degre de couplage (du fort au faible) 

Figure 4-3 

Degres de couplage et niveaux de configuration dynamique. 



Le cycle de mise en aeuvre d'une relation de service 

Les architectures dynamiques permettent aux applications qui les constituent de choisir dynamiquement 
(a l'execution) : 

• les points d'acces des prestataires ; 

• les techniques de liaison (implementations des interfaces) avec les prestataires ; 

• les prestataires des services ; 

• les services (contrats) qu'elles utilisent en tant que clientes. 
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Le cycle de mise en ceuvre d'une relation de service entre deux applications comporte quatre phases : 

1. Information. 

2. Negociation. 

3. Instrumentation. 

4. Execution. 

Selon le niveau de configuration dynamique de l'architecture, chacune de ces phases peut etre 
pratiquement vide d'activite ou, a Finverse, tres chargee. 

Entre la phase 2 et la phase 3 se situe l'evenement ponctuel de signature du contrat de service 
(cloture de l'accord sur le contrat). L'acte de signature peut etre explicite ou implicite, la simple 
continuation de la relation constituant acceptation mutuelle de l'accord. Les acteurs du cycle de mise 
en ceuvre de la relation de service seront denommes, avant la signature du contrat, fournisseurs et 
demandeurs de services, et, apres la signature, prestataires et clients de services. Nous appellerons 
les phases avant la signature (1 et 2) phases amont et les phases apres signature (3 et 4) phases aval 
du cycle de mise en ceuvre d'une relation de service (voir figure 4-4). 
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Figure 4-4 

Phases du cycle de mise en ceuvre de la relation de service. 

Les etats du contrat 

Nous allons distinguer plusieurs etats de contrat, qui sont utilises dans les differentes phases du cycle 
de mise en ceuvre de la relation de service (voir figure 4-5). 

Un contrat executable est un contrat qui contient suffisamment d' informations pour que la prestation 
qu'il regente soit instrumentee et executee. Autrement, un contrat est dit non executable. 

Un contrat negociable est un contrat, executable ou non, qui comprend des clauses variables, objets 
de negociation, lesquelles deviennent « constantes » a l'aboutissement positif de la phase de negociation. 
Les clauses variables peuvent etre renseignees (partiellement ou totalement) ou non renseignees. A la 
convergence de la phase de negociation, un contrat negociable devient/erme (il fait l'objet d'une offre 
ferme ou d'une commande ferme). Un contrat negociable entierement renseigne peut etre executable. 
Une condition necessaire pour qu'un contrat passe a l'etat ferme est qu'il soit executable. 
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Pour certains elements contractuels, la negociation peut etre reportee a une phase ulterieure, qui 
demarre dans le cadre du deroulement de la prestation de services. Ces elements ne sont done pas fermes : 
le contrat est cependant executable par des applications qui disposent des capacites de negociation 
appropriees. 

Un contrat ferme est un contrat non negociable et executable. 

Un contrat signe est un contrat ferme auquel les contractants ont appose leurs signatures. 

Un contrat type est un modele de contrat. Le contrat type peut etre etabli par une organisation 
professionnelle ou un organisme de normalisation, lesquels definissent un service standard et inde- 
pendant des prestataires. Un contrat type peut egalement etre etabli par un prestataire et propose 
systematiquement a ses clients. 

Un contrat (negociable ou ferme) peut etre une occurrence d'un contrat type. 
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Figure 4-5 

Etats de controls et contrats types. 
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Les phases du cycle 

Phase 1 : information 

Dans la phase 1, les fournisseurs et les demandeurs de services s'echangent, eventuellement via des 
services d' intermediation, les informations sur les offres et les demandes de services. La categorisation 
et l'indexation des services, des contrats, des fournisseurs et, dans des architectures plus evoluees, 
des demandeurs de services, sont necessaires a la recherche d' information. 

Phase 2 : negociation 

La phase 2 est la phase de negociation du contrat. Les fournisseurs et les demandeurs s'echangent 
d'abord des intentions et ensuite des engagements, par le biais de protocoles de negociation qui 
amenent le contrat de l'etat negotiable a l'etat signe (ou, sinon, a l'echec de la negociation). La phase 
de negociation ne peut etre agencee et effectuee que par des applications douees de capacites elevees 
de resolution de problemes et de reconfiguration dynamique. 

Phase 3 : instrumentation 

Entre la phase 2 et la phase 3 se situe Yacte de signature du contrat. Cet acte de signature est en 
meme temps la derniere etape de la phase 2 (negociation - cloture de F accord) et la premiere etape 
de la phase 3 (instrumentation - creation de la liaison). La signature marque le passage de 1' accord 
sur le contrat a la mise en ceuvre de la prestation. Lacte de signature peut etre implicite : le passage a 
1' instrumentation du contrat fait office d' acceptation du contrat. 

Apres la signature du contrat, la phase 3 est une phase d'etablissement de la liaison {binding) 
entre le client et le prestataire. La phase d' instrumentation peut aller du simple echange d'adresses 
de communication a des protocoles plus complexes comprenant des phases d'identification, 
d'authentification et d'autorisation. 

Phase 4 : execution 

La phase 4 est la phase de realisation de la prestation de services. Si une interface de gestion de 
service est disponible, cette phase est geree dans le cadre d'un veritable cycle de vie, avec des protocoles 
de demarrage, d' arret, de suspension et de reactivation de la realisation du service. 

Cycle en spirale 

Le cycle de mise en ceuvre de la relation de service se deroule selon un modele en spirale pour les 
architectures a reconfiguration dynamique (voir figure 4-6). Au cours de la realisation du service, un 
nouveau cycle d' information, negociation, instrumentation et execution peut demarrer lorsque, par 
exemple, la phase d' execution integre des mecanismes de gestion de la continuite du service et de 
negociation a la volee de niveaux de qualite qui induisent la reconfiguration dynamique de la relation 
de service. 
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Figure 4-6 

Le cycle en spirale des architectures a reconfiguration dynamique. 



Les niveaux de configuration dynamique 

Nous allons developper trois niveaux de configuration dynamique des architectures orientees services. 
Ces niveaux sont determines surtout par les capacites de configuration dynamique des phases amont 
du cycle de mise en ceuvre de 1' architecture orientee services : 

• configuration dynamique niveau 1 {quasi statique) ; 

• configuration dynamique niveau 2 (avec annuaire) ; 

• configuration dynamique niveau 3 (avec intermediaire). 

Nous avons vu que le modele de F architecture orientee services repose sur trois concepts de base : le 
concept de contrat, de client {demandeur) et de prestataire (fournisseur). Les autres concepts, 
comme ceux de tiers et A' intermediaire, sont reconductibles, eux aussi, a ces concepts de base. Le 
tiers est un prestataire de services annexes qui peuvent etre utilises par les applications d'une archi- 
tecture orientee services dans les differentes phases de mise en ceuvre d'une relation de service 
primaire. L intermediaire est un prestataire de services d'intermediation, dont les clients sont des 
applications orientees services pouvant jouer les roles de clients et de prestataires d' autres services 
dits primaires. Les services d'intermediation peuvent intervenir dans les differentes phases de mise 
en ceuvre de la relation de service primaire. 

Les niveaux de configuration dynamique se distinguent par la presence (ou 1' absence) de tiers et 
d' intermediaries dans les phases 1, 2 et 3 (information, negociation, instrumentation). 
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Dans la configuration niveau 1, il n'y a ni tiers ni intermediates dans les phases d' information, de 
negociation et d' instrumentation (il peut cependant y avoir des tiers et intermediaries dans la phase 
d'execution, necessaires a la realisation de la prestation de services). 

Dans la configuration niveau 2, opere un tiers prestataire du service d'annuaire, dans la phase 1 
(information) et dans la phase 3 (instrumentation). 

Dans la configuration niveau 3, opere un intermediaire, prestataire de differents services d'inter- 
mediation, qui peuvent etre impliques dans les phases 1, 2 et 3 (information, negociation, instrumentation) 
mais egalement dans la phase 4 (execution). 

La configuration dynamique niveau 1 

Dans la configuration dynamique niveau 1 (quasi statique), les applications « se connaissent » a 
l'avance (au moins l'application demandeur connait l'application fournisseur). Se connaitre, dans ce 
contexte, veut dire connaitre FURL d'une ressource racine qui contient les informations ou les 
renvois necessaires a la mise en ceuvre de la relation de service. L'architecture de niveau 1 se carac- 
terise par F absence de tiers et d' intermediaries (voir figure 4-7). Elle est simple a mettre en ceuvre, 
mais son inconvenient reside dans Fabsence presque totale de capacite dynamique (rigidite, manque 
de robustesse, difficulte de montee en charge, etc.). 

Phase 1 : information 

Dans une configuration niveau 1, le demandeur connait le fournisseur de services et le contrat est 
expose par le fournisseur comme une ressource dont FURL est connue ou conventionnelle. Le 
demandeur effectue une inspection : 

• pour confirmer que le contrat est bien celui auquel il s'attendait ; 

• pour recuperer des informations utiles a F instrumentation du contrat (par exemple Fadresse du 
port de reception du fournisseur). 

Si le contrat expose par le fournisseur est ferme (non negotiable), le cycle de mise en ceuvre passe 
directement a la phase d'instrumentation du contrat. 

Phase 2 : negociation 

Cette phase n'est pas vide si le contrat est negotiable et si le demandeur et le fournisseur sont en 
mesure de mettre en ceuvre un protocole de negociation et une configuration dynamique de la relation 
de service. 

Phase 3 : instrumentation 

Le contrat est instrumente, c'est-a-dire que la liaison entre le demandeur et le fournisseur, devenus 
respectivement client et prestataire, est mise en ceuvre. Le client valide, dans le contrat, les informations 
relatives a F implementation de F interface (les conventions d'encodage, les protocoles de transport, les 
ports de reception) pour Fetablissement de la liaison. Le client et le prestataire mettent eventuellement 
en ceuvre un protocole d'authentification reciproque. 
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Phase 4 : execution 

L' execution du contrat est la realisation de la prestation de services. Elle peut eventuellement prevoir 
le redemarrage du cycle de mise en ceuvre, car les conditions de realisation de la prestation de services 
peuvent changer dynamiquement. 
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Figure 4-7 

Configuration dynamique niveau 1 (quasi statique). 



WS-lnspection 

IBM et Microsoft ont propose le langage Web Services Inspection Language (WS-lnspection 1.0 ; http://www-106 

.ibm.com/developerworks/webservices/library/ws-wsilspec.html) qui permet d'inspecter un « site » pour decouvrir 

les services proposes. Le document est accessible par une URL conventionnelle. Le document WS-lnspection 

peut egalement referencer les informations normalement dispersees dans plusieurs documents WSDL et annuaires 

UDDI. 

Le document WSIL d'un prestataire de services est normalement expose a une URL conventionnelle de type : 

http://www.provider.com/service.wsil. 



La configuration dynamique niveau 2 

La configuration dynamique niveau 2 se caracterise par la presence d'au moins un prestataire de 
services d' intermediation : le service d'annuaire (voir figure 4-9). 

Lannuaire 

Dans la litterature sur les architectures orientees services, le terme d'annuaire a diverses significations 
et recouvre plusieurs fonctions ou combinaisons de fonctions. Pour clarifier la problematique, nous 
allons donner une definition ideale du service d'annuaire comme resultat de Fagregation de trois 
services de base (voir figure 4-8) : 

• le service de repertoire des fournisseurs de services avec leurs coordonnees ; 

• le service de referentiel des contrats de service proposes par les fournisseurs (ainsi que des 
documents annexes) ; 

• le service de carnet d'adresses des ports de reception des fournisseurs de services. 
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L'annuaire des services gere les liens entre le referentiel, le repertoire et le carnet. Toutes ces infor- 
mations peuvent etre organisees et indexees par categories (metier et techniques) et dotees d'identi- 
fiants puises dans des systemes de codification. Un service d'annuaire evolue peut gerer une fonction 
ft abonnement/notification : le demandeur s'abonne aux changements de resultat d'une certaine 
interrogation (exemple : les foumisseurs qui offrent un certain contrat type) et le service lui notifie 
tout changement (exemple : l'enregistrement d'un nouveau fournisseur proposant le contrat type). 
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Figure 4-8 

L'architecture logique de l'annuaire de services. 



Le repertoire des foumisseurs 

Le repertoire des foumisseurs gere l'ensemble des informations ayant trait aux foumisseurs (leurs 
coordonnees, par exemple). Un point important est la gestion des relations organisationnelles : par 
exemple la gestion des notions de holding, de groupe, de filiale, de departement, ainsi que la repartition 
geographique. 
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Le referentiel des contrats 

Le referentiel de contrats gere les contrats types, les contrats negociables, les contrats fermes, les 
contrats signes d'une architecture orientee services. Le referentiel des contrats gere egalement les liens 
entre ces entites, c'est-a-dire : 

• le lien entre un contrat type et ses occurrences ; 

• les liens entre les differents « etats » (occurrences de contrats negociables, fermes, signes). 

Le referentiel des contrats devrait etre en mesure de gerer les versions et les configurations des 
contrats. Pour les contrats signes, les versions successives correspondent a des avenants aux contrats. 
Des systemes plus sophistiques peuvent garder la trace des negotiations, avec les differentes versions 
des contrats negociables produits dans le cadre de la negotiation. D'autres systemes peuvent maintenir 
toute sorte de liens entre contrats, et notamment : 

• les liens entre les contrats « primaires » et les contrats « secondares » (des services annexes 
d' intermediation et de tiers) ; 

• les liens circulaires entre les contrats qui regentent des services troques. 

Les fournisseurs de services, et eventuellement les intermediates et les tiers, utilisent le service de 
referentiel des contrats pour publier les contrats types, les contrats negociables et les contrats fermes 
qu'ils entendent proposer (enregistrement, publication, annonce). Les applications clientes recherchent 
les contrats proposes par les prestataires {recherche, decouverte). 

Le carnet d'adresses 

Le carnet d'adresses donne l'ensemble des adresses des points d'acces aux services. Cette information 
devrait etre geree en temps reel (avec les points d'acces en service et le masquage des points d'acces 
temporairement hors service). 

Acces, categorisation et codification 

La presentation (interface) de l'information d'un annuaire de services est generalement organisee 
sous forme de pages blanches, pages jaunes et pages vertes : 

• les pages blanches privilegient Faeces a l'information (les contrats, les points d'acces) via les 
coordonnees au sens large des fournisseurs ; 

• les pages jaunes presentent les informations (coordonnees des fournisseurs, contrats, points 
d'acces) indexes par categories de services, souvent organisees en hierarchie ; 

• les pages vertes proposent un acces a partir des informations utiles a la mise en ceuvre de la relation 
de service (les points d'acces et les liaisons en relation a un contrat type, par exemple). 

La classification et la categorisation des services, des contrats, des fournisseurs et des points d'acces, 
sont des fonctions importantes de 1' annuaire. La classification et la categorisation sont effectuees au 
moyen de taxonomies et de codifications. 

La classification et la categorisation sont indispensables pour reduire les delais de recherche des services, 
des contrats, des prestataires et des points d'acces. Les taxonomies et codifications sont d'autant plus 
interessantes qu'elles deviennent largement acceptees, voir normalisees, et surtout librement disponibles 
(c'est-a-dire qu'elles ne sont pas assujetties a des formes de propriete intellectuelle qui en limitent la 
diffusion). 
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Les pages jaunes represented en fait une organisation de l'annuaire par classes et categories (specia- 
lisation metier, geographique, etc.). 



Taxonomies et codifications standards 

II existe des taxonomies et des codifications standards, qui sont par exemple applicables aux entrees de l'annuaire 
UDDI, comme : 

- NAICS (ensemble de codes pour les secteurs economiques definis par le gouvernement americain) ; 

- UN/SPC (codes produits et services definis par I'ECMA) ; 

- les taxonomies geographiques. 

D'autres taxonomies peuvent etre definies directement par les differents prestataires d'annuaires (Google s'appuie 
sur une taxonomie definie par le projet dmoz - Open Directory Project, qui pretend fournir une taxonomie generate 
organisant I'information disponible sur le Web). 



Phase 1 : information 

Les fournisseurs enregistrent leurs coordonnees, les contrats et contrats types qu'ils proposent, et les 
adresses des points d'acces dans l'annuaire. 

Les demandeurs interrogent l'annuaire pour connaitre les fournisseurs, les contrats et les points 
d'acces des services. Un service d'abonnement aux nouveaux contrats, fournisseurs et aux nouvelles 
adresses selon plusieurs criteres de selection peut etre propose par l'annuaire. 

Phase 2 : negociation 

Cette phase est identique a celle de la phase de negociation qui existe dans la configuration dynamique 
niveau 1. Les demandeurs et les fournisseurs peuvent evidemment conduire plusieurs negotiations 
en parallele suite aux resultats de la phase 1 . 

Phase 3 : instrumentation 

Le contrat est instrumente. Le client et le prestataire s'echangent les informations necessaires a 
l'etablissement de la liaison prealable a l'execution du contrat. 

Phase 4 : execution 

L'execution du contrat est la realisation de la prestation de services. 

Des changements d' information, pouvant avoir une influence sur la realisation de la prestation de 
services, peuvent etre recuperes par le client interesse, soit sur son initiative (par interrogation perio- 
dique de l'annuaire), soit sur initiative de l'annuaire, qui les notifie aux clients abonnes (cela implique 
la capacite du client a recevoir et a traiter des notifications asynchrones de la part de l'annuaire). Par 
exemple, la fermeture d'un point d'acces de la part du prestataire peut etre detectee par le client lors 
d'une defaillance de communication ou notifiee a l'avance par l'annuaire. 

Le cycle de mise en ceuvre de la relation de service peut redemarrer pendant le deroulement de la 
prestation de services, conduisant a la reconfiguration dynamique de cette relation. 
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Figure 4-9 

Configuration dynamique niveau 2 (dynamique avec annuaire). 



La configuration dynamique niveau 3 

L' annuaire est un service qui permet un niveau eleve de configuration dynamique de F architecture. 
Mais, dans la configuration niveau 2, les positions respectives du demandeur et des fournisseurs ne 
sont pas symetriques : F annuaire fonctionne comme une base indexee de services laquelle est rensei- 
gnee par les fournisseurs et interrogee par les demandeurs, ces derniers pouvant beneficier d'un 
service d'abonnement/notification. L' annuaire limite Finformation a Faspect offre de services, car il 
ne gere que les fournisseurs et leurs cordonnees ainsi que les contrats enregistres par ces fournisseurs 
qui representent en fait des offres de services. 

La configuration dynamique niveau 3 fonctionne sur la base d'une architecture d' annuaire symetri- 
que : les demandeurs et les fournisseurs publient leurs coordonnees, leurs ports de reception, les 
contrats types, les contrats negociables et les contrats fermes. Ces contrats, publies par les deman- 
deurs et les fournisseurs, representent respectivement des demandes et des offres de services (types, 
negociables, fermes). 
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L'annuaire UDDI 

L'annuaire UDDI offre les services de repertoire et de carnet d'adresses. II ne pourvoit pas de fonctions avancees 
de gestion de referentiels de contrat ou de documents annexes. L'annuaire est largement implements et present 
dans les offres des acteurs principaux (IBM, Microsoft, etc.). Ces implementations peuvent etre utilisees pour la 
mise en oeuvre d'annuaires prives, dont I'acces est limite en intranet ou extranet (voir chapitre 11, Decouvrir un 
service avec UDDI, et le chapitre 12, Publier un service avec UDDI). 
Dans un annuaire UDDI, on trouve des objets de quatre types : 

- busi ness Enti ty : organise les informations sur le fournisseur de services ; 

- busi nessServi ce : organise les informations sur le service fourni ; 

- bi ndi ngTempl ate : organise les informations sur llnstrumentation du service (points d'acces, etc.) ; 

- tModel : organise les informations sur la description du service (pointeurs vers des documents WSDL, etc.). 
Une busi ness Enti ty peut offrir plusieurs bus i nessServi ce, qui a leur tour peuvent presenter chacun plusieurs 
bi ndi ngTempl ate (structure arborescente). Chaque bi ndi ngTempl ate exhibe un lien vers un tModel . 

Un annuaire UDDI 2.0 est accessible de la meme fagon qu'un service Web : I'interface d'acces est decrite par un 

document WSDL 1.1 et le protocole d'echange est SOAP 1.1. Son interface (API) est essentiellement partagee en 

une partie enregistrement et une partie recherche et decouverte. 

IBM, Microsoft et d'autres fournisseurs proposent des annuaires UDDI publics accessibles sur Internet, qui se 

synchronisent entre eux. 

OASIS est desormais en charge de revolution des specifications UDDI. Cette organisation propose par ailleurs 

une autre specification d'annuaire et de referentiel : ebXML Registry Services Specification, version 2.0 (publiee le 

6 decembre 2001). Cette specification definit les interfaces d'acces, la securite et le format d'enregistrement des 

informations. L'annuaire ebXML, dont il existe des implementations disponibles, gere differentes entites comme les 

CPP (Collaborative protocol profiles) pour les participants a I'echange, les BPS (Business process specifications) 

ainsi que des schemas de classification et categorisation. 



Intermediate de base 

La fonction de base d' intermediate dans la configuration dynamique niveau 3 est une fonction 
d'annuaire symetrique, enrichie du cote demandeur : l'intermediaire gere non seulement les fournis- 
seurs et leurs offres (comme un annuaire classique), mais aussi les demandeurs : leurs coordonnees, 
leurs demandes de services (des contrats qui represented des demandes de services), leurs points 
d'acces. 

L'intermediaire pourvoit differentes fonctions utiles a la mise en relation des demandeurs et des four- 
nisseurs sur la base respective de leurs demandes et de leurs offres. 

La fonction de base de l'intermediaire est V appariement entre demandes et offres (voir figure 4-10). 
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Figure 4-10 

Configuration dynamique niveau 3 (dynamique avec intermediation). 



Intermediate evolue 

La gestion de la publicite et de la discretion sur les identites (les coordonnees) des fournisseurs et des 
demandeurs et sur les contrats, offerts et demandes, est la deuxieme fonction de Fintermediaire. 
Cette gestion peut varier de la publication, sans restriction d'acces, de Fidentite et du contrat (offre 
ou demande), a la discretion la plus totale sur Fidentite et sur le contrat (offre ou demande), en 
passant par des strategies intermediaires (publication de contrats anonymes, publication de demandes 
et d'offres categorisees mais sans contrat et ainsi de suite). Lorsqu'il est question d'anonymat, 
Fintermediaire opere en tant qu' agent (au nom d'un client ou d'un prestataire) dans les phases amont 
de la mise en ceuvre de la relation de service. La confiance dans Fintermediaire remplace la confiance 
dans le demandeur ou le fournisseur anonyme. 

Recrutement de clients 

C'est une fonction d' intermediation specialisee. Le fournisseur fait une requete de recrutement de 
clients sur une offre. Lintermediaire lui retourne la liste des demandeurs qui ont enregistre une 
demande qui s'apparie, selon des criteres plus ou moins stricts, a Foffre. Les demandeurs en question 
ont evidemment accepte, lors de Fenregistrement de leur demande, la publication de leur identite 
avec la demande. Le fournisseur contactera directement les demandeurs pour eventuellement nego- 
cier et signer un contrat de service. Des modes de negociation many-to-one comme les encheres 
(dans les differentes formes d'encheres : anglaise, hollandaise, etc.) peuvent etre envisages (voir plus 
loin la section « Negociation ») s'ils sont appropries et si F infrastructure s'y prete. Lintermediaire 
peut fournir le service de teneur de place d'echange, qui trace les echanges de negociation (garantissant 
eventuellement la non-repudiation). Les demandeurs ne connaissent prealablement ni Fexistence ni 
Fidentite du fournisseur qui prend F initiative du contact. 



L'architecture orientee services 

Premiere Partie 



Contrat (negotiable) 




4. Execution 



Figure 4-11 

Recrutement de clients. 

Recommandation de prestataires 

C'est une fonction d' intermediation specialisee. Le demandeur fait une requite de recommandation 
de prestataires sur une demande. L' intermediate lui retourne la liste des fournisseurs qui ont enregistre 
une offre qui s'apparie, selon des criteres plus ou moins stricts, a sa demande. Les fournisseurs en 
question ont evidemment accepte, lors de Fenregistrement de leur offre, la publication de leur identite. 
Le demandeur contactera directement les fournisseurs pour eventuellement negocier et signer un ou 
plusieurs contrats de service. Des modes de negociation one-to-many comme le RFP (Request for 
proposals) peuvent etre envisages (voir plus loin la section « Negociation »). L' intermediate peut la 
aussi fournir le service de teneur de place d'echange, tiers de confiance qui trace les echanges de 
negociation (garantissant eventuellement la non-repudiation). Les fournisseurs ne connaissent a 
priori ni Fexistence ni Fidentite du demandeur qui prend Finitiative du contact. 
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Figure 4-12 

Recommandation de prestataires. 
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Courtier 

Le courtier est un intermediaire evolue qui met en ceuvre les fonctions d' intermediation de base, de 
recrutement de clients et de recommandation de prestataires, ainsi que, eventuellement, les fonctions 
de teneur de place d'echange (voir plus loin la section « Le teneur de la place d'echange »). Le 
service de courtage peut couvrir entierement les phases amont du cycle de mise en ceuvre du service. 
Le courtier peut notamment conduire directement les negotiations des deux cotes (demandeur et 
fournisseur) et amener les parties a un accord sur un contrat executable sans qu'il y ait eu contact 
direct entre demandeur et fournisseur dans les phases amont. En revanche, son apport se limite a la 
seule signature - 1' instrumentation et l'execution du service etant accomplis par echange direct entre 
client et prestataire. 
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Figure 4-13 

Courtier. 



Intermediation a /'execution 

Les intermediaries que nous avons presentes jusqu'ici participent aux phases amont de la mise en ceuvre 
d'un service. L instrumentation et l'execution du service sont directement gerees par le demandeur et 
le fournisseur, qui deviennent respectivement client et prestataire du service. 

Cependant, un intermediaire peut aussi participer aux phases aval, jusqu'a assurer directement une 
partie de la prestation. De ce fait, 1' intermediaire a l'execution peut cacher reciproquement les identites 
des fournisseurs/prestataires et des demandeurs/clients car il apparait comme client au prestataire et 
comme prestataire au client. 

En fait, le principe de base de 1' intermediation dans les phases aval est que tout ou partie des actes de 
communication servant a instrumenter, preparer, gerer et effectuer la prestation de services, qui est 
toujours fournie par le prestataire, s'effectuent entre le client et l'intermediaire d'un cote, et l'inter- 
mediaire et le prestataire de F autre. 
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Figure 4-14 

Intermediaire a V execution. 



Un exemple d'intermediaire a Fexecution « pur » est le coordinateur du protocole de transaction en 
deux etapes (voir le chapitre 20, « Gestion des transactions »), qui se charge de coordonner, pour le 
compte d'une application qui agrege une prestation complexe dans laquelle plusieurs applications 
interviennent, la confirmation ou Fannulation de la transaction. Ce role est « pur » : le coordinateur 
n'intervient dans la mise en ceuvre d'aucune des prestations applicatives qui s'agregent dans la 
prestation globale, mais se limite a une tache de coordination technique. 

Dans le cas le plus general, la difference entre intermediation a Fexecution et agregation de services 
(presentee dans la section « Approches de conception d' architectures orientees services ») tend a 
s'estomper. L' intermediaire a Fexecution peut mettre en ceuvre des strategies sophistiquees d'agrega- 
tion et de configuration dynamique des services, dont la complexite peut etre cachee au demandeur/ 
client. La figure 4-15 illustre une architecture dans laquelle la relation entre demandeur/client et 
intermediaire est representative du niveau 1 de configuration dynamique (avec toute la simplicite de 
mise en ceuvre du client qui en decoule). A Fexecution, F intermediaire evolue peut garantir un 
niveau de gestion des arrets et de la continuite de service de type/a;7 over (presentee dans le chapitre 
precedent) via un niveau plus eleve de configuration dynamique de la relation avec les fournisseurs/ 
prestataires. 
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Figure 4-15 

Intermediaire a I'execution qui rend I 'architecture quasi statique pour le client. 

Negociation 

La realisation effective de la phase de negociation du cycle de mise en ceuvre de la relation de service 
ajoute une dimension dynamique supplementaire a 1' architecture orientee services. 

La negociation aboutit a la finalisation dynamique du contrat et done a une configuration dynamique 
de la prestation de services. Pour gerer une activite de negociation, le demandeur/client et le fournis- 
seur/prestataire doivent posseder des capacites sophistiquees telles que : 

• la capacite a negocier : cela implique, d'un cote la mise en ceuvre de protocoles de negociation et, 
de 1' autre cote, la mise en ceuvre de regies et d'heuristiques pour conduire le processus ; 

• la capacite a mettre en ceuvre une relation de service definie dynamiquement par le resultat de la 
negociation : cela implique, pour le prestataire, la capacite a reconfigurer dynamiquement la pres- 
tation qu'il pourvoit, et pour le client, la capacite a reconfigurer dynamiquement l'utilisation de la 
prestation. 

L important, en ce qui concerne 1' architecture orientee services, est la definition et la mise en place de 
protocoles normalises de negociation, qui constituent 1' infrastructure qui rend la negociation possible. 
Le reste, la capacite a negocier et a configurer dynamiquement la production et la consommation de 
services, appartient aux possibilites et aux capacites des applications impliquees. 

La negociation d'un contrat peut impliquer un ou plusieurs demandeurs et un ou plusieurs foumisseurs : 

• protocoles one-to-one (un demandeur, un fournisseur) ; 

• protocoles one-to-many (un demandeur, plusieurs foumisseurs) ; 

• protocoles many-to-one (plusieurs demandeurs, un fournisseur) ; 

• protocoles many-to-many (plusieurs demandeurs, plusieurs foumisseurs). 

Des protocoles « electroniques » de negociation one-to-one, many-to-one (encheres), one-to-many 
{request for proposals), many-to-many (marche generalise) ont fait l'objet d'etudes et de mises en 
ceuvre diverses et variees, particulierement avec le developpement du commerce electronique. Ces 
protocoles electroniques ont pour objet des echanges marchands, mais pourraient etre adaptes a la 
negociation des prestations de services informatiques. 
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Les etapes du processus de negotiation 

Le but principal d'un protocole de negotiation est d' organiser un processus qui aboutit a un accord 
sur un contrat de service executable qui satisfait les parties. Un protocole de negotiation sophistique 
est organise par etapes intermediaries (information, intention) et finales (engagement, cloture), dans 
lesquelles la semantique des actes de communication que les interlocuteurs s'echangent evolue dans 
le sens d'une augmentation du niveau d'engagement sur le contrat objet de la negotiation. Chaque 
etape intermediate est optionnelle et peut etre sautee : la seule etape necessaire est 1' engagement, 
dans laquelle soit le fournisseur emet une offre ferme (un contrat ferme), soit le demandeur emet une 
commande ferme (un contrat ferme). L'interlocuteur ne peut repondre que par une acceptation ou par 
un refus. 

Information 

La premiere etape est une etape d'echange d' information. Cette etape se confond avec la phase 
homonyme du cycle de vie de la mise en ceuvre de la relation de service (voir figure 4-4) : dans le 
contexte du processus de negotiation, elle doit etre comprise comme une etape d'information speci- 
fique sur les prestations de services susceptibles de faire partie du contrat. En fait, le demandeur 
communique son interet potentiel, en tant que client, pour des services ayant certaines caracteristiques 
et le fournisseur communique les caracteristiques des services dont il est prestataire. Cette etape est 
purement informationnelle, il n'y a aucune expression de besoin ou d'engagement concret, ni de la 
part du fournisseur, ni de la part du demandeur. 

Intention 

Si le processus de negotiation ne s'est pas arrete avant par la defection d'un des interlocuteurs, il peut 
passer a l'etape d'expression d'intentions. Les actes de communication que les interlocuteurs 
s'echangent dans cette etape manifestent l'intention (sans engagement ferme) de mettre en ceuvre 
une relation de service. Le demandeur manifeste l'intention de commander une prestation conforme 
a un certain contrat, et le fournisseur manifeste l'intention d'effectuer une prestation conforme a un 
certain contrat plus ou moins proche du premier. 

Engagement 

Le processus de negotiation peut s'arreter a l'etape d'expression d'intention par defection d'un des 
interlocuteurs. S'il continue, il entre, tot ou tard, dans l'etape d'engagement. Les actes que les inter- 
locuteurs s'echangent dans cette etape manifestent l'engagement ferme de l'emetteur par rapport a un 
contrat executable. II faut bien noter que, dans la phase d'engagement, les actes de communication 
ont toujours une signification double et conditionnelle : l'engagement de l'emetteur et la requete 
d'engagement au recepteur, en sachant que l'engagement de l'emetteur est conditionne par la reponse 
du recepteur et que, sans engagement reciproque de ce dernier, il ne constitue plus une obligation 
pour l'emetteur. 

Cloture 

L'etape de l'engagement peut comprendre plusieurs echanges de propositions et contre-propositions, 
mais il arrive un moment ou un des interlocuteurs emet une proposition de contrat qui tolere seulement 
deux reponses possibles : 1' acceptation et done la cloture de 1' accord ou le refus et 1' arret definitif du 
processus de negotiation. 
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Avec la cloture du contrat, s'ouvre le passage aux phases aval du cycle de mise en ceuvre de la relation 
de service (instrumentation, execution). 

Le teneur de place d'echange 

Le teneur de place d'echange (ou place de marche) est un prestataire de service de plate-forme et 
de tiers de confiance pour l'activite de negociation et eventuellement pour certaines activites de suivi 
de l'execution du contrat. Les fonctions specifiques du service tiers de tenue de la place d'echange 
peuvent etre Fauthentification des participants a la negociation, la non-repudiation des echanges dans 
le processus de negociation, 1' orchestration de protocoles de negociation qui demandent des services de 
coordination, comme les encheres, mais aussi le suivi a l'execution de la tenue de certains engagements 
contractuels, notamment ceux qui touchent la qualite de service. 

Conclusion 

Le modele d' architecture orientee services est un outil conceptuel puissant, car il est fonde sur un 
nombre reduit de concepts mais s'applique pratiquement a tout type d' architecture repartie. Ce modele 
puise ses fondements dans des recherches, des pratiques et des technologies utilisees largement et 
depuis longtemps en informatique repartie. II peut se developper et se diffuser grace a l'essor des 
technologies de services Web. 

Les technologies de services Web disponibles aujourd'hui couvrent les fonctions de base de l'infra- 
structure necessaires a la mise en ceuvre d' architectures orientees services : notamment le formalisme 
d'une partie importante (la definition des interfaces) du contrat de service (WSDL), les protocoles 
d'echange entre applications (SOAP, XML/RPC, etc.), les outils et les mecanismes propres a 
l'exploitation d' architectures dynamiques (l'annuaire UDDI, les generateurs de proxies dans les 
langages de programmation les plus utilises. . .). Les protocoles et les outils A' infrastructure necessai- 
res au deploiement d' applications critiques sur grande echelle, comme la gestion de la securite (WS- 
Security) et la gestion des transactions (WS -Coordination, WS-Transaction, BTP), sont en matura- 
tion, en termes de specification et d' implementation, tandis que d'autres, comme la fiabilite des 
echanges (vois le chapitre 18, Fiabilite de l'echange) sont encore en gestation. Le domaine des langages 
de description des processus metier, outils indispensables pour l'agregation de services, est en pleine 
effervescence (voir le chapitre 21, Gestion des processus metier). Le developpement des ingredients 
technologiques necessaires a la mise en place d' architectures orientees services progresse done 
relativement rapidement, compte tenu de la complexite de la problematique. 

Les architectures orientees services, mises en ceuvre via les technologies de services Web, vont avoir 
comme cible privilegiee F automation de processus metier infra et interorganisations. Ces processus 
sont aujourd'hui partiellement pris en charge par des systemes informatiques, mais se deroulent a 
l'aide d' interventions directes des acteurs humains sur des taches executives situees dans toutes les 
phases et surtout dans les points d'interaction entre organisations differentes. Avec la mise en place 
d' architectures orientees services, de plus en plus de taches executives seront prises en charge direc- 
tement par les applications reparties et les utilisateurs s'orienteront plutot vers des taches de conception, 
de parametrage, de pilotage, de surveillance et de reparation des processus ainsi automatises. 

La vraie valeur de 1' intervention humaine, dans les taches executives les plus banales, pour lesquelles 
un programme est beaucoup plus rapide et precis, se situe dans la capacite superieure que nous avons 
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lorsqu'il s'agit de traiter les situations imprevues, d'erreur, d'attente et d' incertitude. Au final, c'est 
cette capacite humaine qui rend globalement robustes des processus semi-automatises localement 
assez peu fiables. 

Pour obtenir un niveau comparable de robustesse globale avec des processus metier fortement auto- 
matises, le niveau de robustesse technique et applicative locale (la capacite a traiter les situations 
d'erreur, d'echec, de defaillance, d'attente et d'incertitude au niveau technique et applicatif, en 
l'absence d' intervention humaine directe) des applications reparties participantes doit augmenter de 
facon sensible par rapport au niveau actuel. 

Nous savons que les caracteristiques propres aux architectures reparties, qui les differencient des 
architectures centralisees, sont : 

• la possibilite de defaillance partielle et independante des elements constituants, au niveau logiciel 
et materiel ; 

• les temps de latence impredictibles et la possibilite de defaillance de F infrastructure materielle et 
logicielle de communication ; 

• la remontee au niveau de la logique applicative des situations d'erreur, d'echec, de defaillance, 
d'attente et d'incertitude, ainsi que de leurs consequences. 

Nous pouvons citer un exemple tres simple : le programme client qui effectue le choix dynamique d'un 
prestataire d'un service defini par un contrat type doit tenir compte, dans son choix, non seulement de 
criteres metier, mais aussi de cri teres techniques comme la disponibilite et l'accessibilite (en temps 
reel) des prestataires. 

Par ailleurs, pour la raison evoquee ci-dessus, les proprietes de qualite de service (performance, 
accessibilite, fiabilite, disponibilite, continuite, robustesse. . .) vont prendre une importance excessive 
comme facteur de competitivite d'une offre de services Web. Un prestataire peut concevoir et mettre 
en ceuvre un service fonctionnellement parfait, qui repond pertinemment aux besoins des clients et 
utilisateurs, mais si le serveur n'est pas accessible en temps reel, au moment exact oil le client en a 
besoin, le prestataire ne sera pas choisi, et tout 1' effort mis dans la conception et la mise en ceuvre 
fonctionnelle sera rendue vaine par des choix operationnels malheureux. 

La solution automatique de tous les problemes operationnels, qui peuvent surgir lors de la prestation 
de services Web, n'est pas concevable aujourd'hui : les architectures de services Web doivent etre 
cogues de facon a prevoir des canaux et des outils d' intervention efficaces a destination des acteurs 
humains en charge du parametrage, du pilotage, de la surveillance et de la reparation des processus 
metier automatises. Par exemple, la possibilite de passer « manuellement » des actions et transactions 
compensatoires doit faire systematiquement partie des specifications de ces architectures et done etre 
incluse d'emblee dans les contrats proposes par les applications constituantes. 

Par ailleurs, les premiers services Web sont et seront obtenus tout simplement par la mise en place 
d'interfaces SOAP pour acceder aux memes applications deja accessibles sur le Web via le navigateur 
(c'est le cas, par exemple, d'un des services Web le plus populaires, celui qui permet d'acceder par 
programme au moteur de recherche Google). Le service Web s'ajoute au site Web deja existant 
comme deuxieme canal d'acces a 1' application : 1' intervention humaine reparatrice est done en principe 
deja possible. 
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L' alternative a la complication et a la complexification de la logique applicative se trouve dans 
1' amelioration drastique de la qualite de service obtenue par un saut technologique de 1' infrastructure 
(gestion de la fiabilite des echanges, gestion des transactions, gestion de la securite) ainsi que dans la 
disponibilite a grande echelle de technologies materielles et logicielles qui permettent la mise en 
ceuvre d' architectures adaptatives, avec une capacite tres elevee de reconfiguration dynamique. 

Les architectures de grilles d'ordinateurs (Grid computing ; http://www.globus.org) represented une 
technologie emergente, dont la combinaison avec les technologies de services Web est en marche 
(Open Grid Services Architecture ; http://www.globus.org/ogsa). La technologie des grilles promet de 
resoudre une partie des problemes evoques, via des mecanismes de virtualisation de ressources 
redondantes de temps de calcul, de memoires primaires, de capacites de stockage, de connexions 
reseau. IBM, qui appuie fortement, avec Microsoft et d'autres acteurs du marche, Factivite de Grid 
computing, a lance par ailleurs un programme ouvert de recherche, appele Autonomic computing 
(http://www.ibm.com/research/autonomic), dans le but de mettre en ceuvre des systemes repartis capables 
de se proteger et de se reconfigurer de facon reactive et proactive, et done de garantir un niveau eleve 
et continu de qualite de service aux applications. D'autres acteurs technologiques majeurs (Intel, 
Hewlett-Packard) travaillent sur les memes themes. 

Ces efforts de recherche et de developpement donneront certainement des resultats dans les annees 
qui viennent, mais pas dans un futur proche. La mise en ceuvre d' applications avec une capacite elevee 
de prise de decision et de resolution de problemes en temps reel reste le vrai defi des architectures 
reparties d'aujourd'hui. Le modele conceptuel et operatoire de F architecture orientee services et des 
technologies de services Web associees est un instrument qui peut aider a remporter ce defi. 
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Ce chapitre presente, dans Fordre : 

• URI, URN, URL, trois sigles qui se rapportent au mecanisme utilise par le Web pour identifier et/ 
ou localiser une ressource ; 

• MIME, technologie permettant de vehiculer des objets de toute sorte sur Internet, tres importante 
dans la mesure ou de nombreux autres protocoles l'utilisent, et en particulier SMTP et HTTP ; 

• HTTP/1 . 1 , protocole reseau fondamental en tant que tel, qui est en outre le moyen de transport des 
messages le plus utilise pour les services Web ; 

• SMTP, alternative a HTTP en tant que moyen de transport des services Web. 
Quatre sous-chapitres ont ete ajoutes en annexe pour appuyer cette presentation : 

• le modele OSI dTSO qui est utilise comme reference pour decrire les architectures reseau ; 

• le modele d' architecture reseau TCP/IP ; 

• une description du mode de publication des RFC, ces documents qui regissent en grande partie la 
vie dTnternet et des technologies utilisees ; 

• une liste de definitions des acronymes des nombreuses organisations qui participent a la gestion 
dTnternet et a l'etablissement des standards technologiques. 

URI, URL, URN 

Le Web est une formidable mine d' informations, de documents, de programmes et de services, bref, 
de ressources en tout genre. II etait primordial de definir un mecanisme permettant aux utilisateurs et 
aux programmes de nommer et de localiser ces ressources. C'est l'objectif des URI (Uniform 
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Resource Identifier) dermis par un standard Internet (Draft Standard) propose par 1'IETF sous la 
reference RFC2396 (aout 1998). 

Ce mecanisme d' identification et de localisation est utilise non seulement par les protocoles de base 
du Web que sont HTTP, FTP ou Telnet, mais aussi par la plupart des technologies recentes telles que 
les espaces de noms (namespaces) XML, SMIL, ou SVG. Les enjeux sont suffisamment importants 
pour qu'un groupe de travail du W3C, en coordination avec 1TETF, soit dedie a ce sujet depuis juillet 
2000 (http://www.w3c.org/addressing). 
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Figure 5-1 

URI, URL, URN. 



Les URI sont classes en trois groupes (voir figure 5-1) : 

• ceux qui permettent de localiser des ressources sur un reseau, appeles URL (Uniform Resource 
Locator) ; 

• ceux qui permettent d' identifier et de nommer des ressources de maniere unique et persistante, 
appeles URN (Uniform Resource Name) ; 

• et ceux qui permettent a la fois de localiser et d' identifier une ressource. 

Syntaxe d'un URI 



Jeu de caracteres 

Un URI n'utilise qu'un jeu restreint de caracteres (chiffres, lettres et quelques symboles) car il doit 
pouvoir etre utilise tout aussi bien avec des moyens de communication informatises que non informatises 
(papier, etc.). II est constitue : 

• de caracteres reserves (« ; », « / », « ? », « : », « @ », « & », « = », « + », « $ », « , ») qui servent 
de delimiteurs ; 

• de chaines de caracteres codes en ASCII US ou a Faide de sequences d'echappement commencant 
par le signe « % » (par exemple : « %2D » qui est le caractere « - »). 
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Composition d'un URI 

Un URI est toujours constitue de la maniere suivante : 

| <modele>:<chemin ou partie specifique du modele> 

L'enregistrement de nouveaux modeles ou scheme est soumis a une procedure decrite par le RFC2717. 
La liste des modeles enregistres est, quant a elle, geree par 1'IANA (http://www.iana.org/assignments/uri-schemes). 
On y trouve notamment : 

• ftp (RFC1738) ; 

• http (RFC2616) ; 

• mailto(RFC2368); 

• file (RFC 1738); 

• etc. 

Le modele ou scheme definit l'espace de noms de FURI et peut done introduire des restrictions dans 
la syntaxe ou la semantique du chemin. En d'autres termes, la syntaxe d'un URI depend du modele 
utilise. 

II existe neanmoins une syntaxe generique des URI, que voici : 

<modele>://<autori te><chemin> ?<requete> 
Par exemple : 

I ftp://www.monsite.com/pub 
http:/ /www. monsite.com/index.htm?paraml=l&param2=essai 
file:///c:/program%20files/monfichier.txt 

Les modeles qui impliquent F utilisation d'un protocole sur IP utilisent la syntaxe suivante pour decrire 
la partie autorite : 

<uti 1 isateur>@<hote>:<port> 

Cette syntaxe peut se traduire par « utilisateur accede a hote sur le port IP ». La syntaxe de la partie 
« utilisateur » peut elle-meme comprendre le mot de passe, meme si cela est fortement deconseille 
puisqu'il est transmis en clair sur le reseau. Les parties « utilisateur » et « port » sont optionnelles. 

L'exemple suivant ouvre une connexion FTP sur le site www.monsite.com sur le port 8000, login 
« anonymous », mot de passe « nopwd » : 

ftp: //anonymous: nopwd@www.monsite.com: 8000 

Si un URI doit traduire une hierarchie, on utilise alors le caractere « / » pour separer les elements de 
la hierarchie. Cette syntaxe ressemble a celle qui est utilisee sur les systemes Unix pour les chemins 
de fichiers, cependant il ne doit pas y avoir d'amalgame : un URI ne designe pas forcement un fichier, 
et si e'est le cas, il ne coincide pas forcement avec le chemin reel du fichier sur le systeme hote (il 
s'agit alors d'un chemin logique). 

La syntaxe de la partie « requete » depend du modele, mais une forme commune est la suivante : 
<parametrel>=<val eur>&<parametre2>=<valeur> ... 
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URN 



Comme nous Favons dit, un URN a pour objectif de nommer une ressource independamment de sa 
localisation. Un modele (scheme) specifique a ete defini par le RFC2141 et est utilise en tant que 
standard pour identifier des ressources sur le Web. 

Sa syntaxe est la suivante : 

urn:<espace de nomsXidentif iant au sein de 1'espace de noms> 
Par exemple : 
| urn:MonEspace:MonIdentif iant 

MIME 

MIME (Multipurpose Internet Mail Extensions) est un standard Internet (« Draft Standard ») propose 
par 1'IETF sous les references RFC2045, RFC2046, RFC2047, RFC2048 et RFC2049 (dernieres 
RFC datees de novembre 1996). 

Cette specification a pour objectif : 

• de permettre Fechange sur Internet de messages dont le contenu textuel est code avec un autre jeu 
de caracteres que F ASCII US sur 7 bits (utilise historiquement sur le Web) ; 

• de definir un ensemble extensible de formats binaires permettant de transporter dans ces messages 
tout type de contenu non textuel (audio, video, HTML, etc.) ainsi que des contenus mixtes 
(« multipart ») ; 

• de permettre le codage des informations d'en-tetes de ces messages avec un autre jeu de caracteres 
que F ASCII US. 

En d'autres termes, c'est un standard qui permet d'echanger des messages multimedias sur Internet 
entre des systemes informatiques heterogenes. 

Description d'un message MIME 

MIME introduit des lignes d'en-tetes dans les messages : 

• une ligne « MIME-Version: 1.0- »; 

• une ligne « Content-Type » qui precise le format du message ; 

• une ligne « Content-Transfer-Encoding » qui precise Fencodage de ce type de contenu. 
Deux encodages fondamentaux sont utilises par les messages MIME : 

• Quoted-Printable (ou QP), qui permet de coder n'importe quel jeu de caracteres sur 7 bits (par 
souci de compatibilite) ; 

• Base64, qui permet de coder n'importe quel fichier binaire. 

Ces deux encodages ne sont pas obligatoires mais fortement recommandes. 

Le format du message est defini par un type MIME. La definition de ces types est extensible (la 
liste officielle est disponible a http://www.isi.edu/in-notes/iana/assignments/media-types/media-types) et 
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V implementation de chacun de ces types est du ressort des applications informatiques. Seuls 
quelques types de base doivent obligatoirement etre pris en charge. 

Un type MIME est identifie par un label type/sous-type; parametres, ce qui permet d'organiser les 
formats d'apres des types de base : 

• text, image, audio, video, appl ication ; 

• plus deux types composites : message et multipart. 

Cela permet ensuite de decliner ces types de base en fonction des besoins, comme : image/jpeg ou 
text/xml . 

Dans l'exemple suivant, le message contient du texte, utilise un jeu de caracteres ISO-Latin-1 et est 
code en QP : 

MIME-Version: 1.0 

Content-Type: text/plain; charset=iso-8859-l 
Content-Transfer-Encoding: quoted-printable 

Le type multipart/... permet de creer des contenus mixtes, c'est-a-dire des messages constitues de 
plusieurs parties de formats differents. Typiquement, il s'agit d'un message contenant un texte et un 
flchier attache. Ce type precise obligatoirement un parametre boundary qui permet de specifier le 
separateur utilise entre les parties du message. 

Le message suivant contient du texte et un fichier attache : 
MIME-Version: 1.0 

Content-Type: multipart/mixed; boundary="monSeparateur" 

Ceci est une zone de commentaire du message au format MIME 

--monSeparateur 

Content-Type: text/plain; charset=iso-8859-l 

Content-Transfer-Encoding: 8bit 

Ceci est le contenu textuel du message 

--monSeparateur 

Content-Type: appl i cat ion/octet- stream 

Content-Transfer-Encoding: base64 

Content-Description: nom du fichier.doc 

Content-Disposition: attachment;filename=" nom du fichier.doc " 

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAA 

--monSeparateur- 



HTTP 1.1 



HTTP (HyperText Transfer Protocol) est un standard Internet (Draft Standard) propose par 1'IETF 
sous la reference RFC2616 (derniere RFC datee de juin 1999) et utilise sur le Web depuis 1990. 

HTTP est un protocole application generique (couche 7, voir en annexe la section « Le modele de 
reference OSI de 1TSO »), qui permet de transferer des messages au format MIME entre un client et 
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un serveur. II est largement utilise par de nombreux types de clients (PC, PDA, CD-Rom, etc.), des 
moyens de transport varies (depuis les reseaux sans fil jusqu'aux liaisons optiques transoceaniques) 
et sur des architectures plus ou moins complexes composees de passerelles, de hierarchies de caches, 
etc. 

Presentation generate 

Le protocole HTTP utilise un jeu de requites/ reponses entre un client, qui initie le dialogue, et un 
serveur. La communication peut etre directe entre les deux acteurs mais elle peut egalement faire 
intervenir trois types d' intermediaries, que voici : 

• un proxy, c'est-a-dire un agent qui transfere les messages vers le serveur apres en avoir reecrit tout 
ou partie du contenu ; 

• une passerelle, c'est-a-dire un agent qui agit comme une surcouche pour un serveur sous-jacent 
utilisant un autre protocole ; cet agent se charge de traduire les messages pour permettre leur transfert 
vers ce serveur tiers ; 

• un tunnel, c'est-a-dire un relais qui se charge de transmettre le message entre deux points de 
connexion sans modification du message (a travers un intermediate tel qu'un pare-feu). 

En dehors des tunnels, tous les autres intermediaries peuvent implementer des fonctions de cache : il 
s'agit de garder localement une copie de la reponse tant que celle-ci est valide et de retourner cette 
reponse au client sans interroger a nouveau le serveur (ce qui amene un gain de performance et de 
trafic reseau). 

La connexion etablie par le protocole HTTP 1.0 est par defaut volatile : le client ouvre une connexion 
avec le serveur, envoie une requete et se met en attente de la reponse ; le serveur recoit la requete, la 
traite, envoie la reponse et ferme la connexion. Pour garder la connexion ouverte au-dela du traitement 
de la requete/reponse courante, le client doit explicitement demander le maintien de la connexion 
(Keep-Alive). A son tour, le serveur doit expliciter sa capacite a maintenir la connexion dans la 
reponse. En HTTP 1.1, la connexion est persistante par defaut et il faut que le client ou le serveur la 
ferment explicitement. 

En HTTP 1 .0, le protocole est synchrone et half-duplex : sur une connexion, meme persistante, le 
client envoie une requete et se met en attente de la reponse avant d'envoyer la requete suivante. En 
HTTP 1.1, les requetes peuvent etre acheminees en sequence (pipelining) sur une connexion sans 
attendre les reponses respectives. Le serveur doit acheminer les reponses dans le meme ordre des 
requetes : la correlation requete/reponse est maintenue, dans une connexion, par correspondance de 
numero d' ordre. 

Le protocole HTTP est a l'origine sans etat, c'est-a-dire qu'il est incapable de traiter une succession 
de reponses/requetes issues du meme client comme un dialogue de session : le client envoie une 
requete, le serveur y repond, mais il n'y a pas de moyen pour communiquer entre client et serveur des 
informations sur le contexte du dialogue (l'etat de la session). Ce fonctionnement s'est vite avere 
problematique pour les sites Internet qui ont souvent besoin de suivre les actions d'un utilisateur au 
sein d'une session (par exemple, pour une prise de commande). C'est pour cette raison qu'un meca- 
nisme de gestion d'etat a ete ajoute au protocole dans la RFC2965 (Proposed Standard), il introduit 
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de nouveaux en-tetes (cookies) qui permettent d'echanger des donnees d'etat tout au long des echanges 
entre un client et un serveur. 

Enfin, HTTP utilise en general TCP/IP sur le port TCP 80 (par defaut), mais en theorie tout autre 
protocole peut etre utilise. 

Description d'un message HTTP 

Un message HTTP est soit la requete d'un client, soit la reponse d'un serveur (ou d'un intermediate). 
Une requete HTTP 1.1 est composee de : 

• une ligne de requete qui precise la methode utilisee, l'URI auquel s'applique cette methode et la 
version du protocole HTTP utilise ; 

• zero ou plusieurs champs d' en-tetes du type « champ:valeur ». Les en-tetes sont de type general, 
requete ou entite 

• une ligne vide ; 

• un corps de message MIME optionnel : la presence ou non de ce contenu depend de la commande 
utilisee. La forme de ce corps de message depend du type et de l'encodage utilise (champs 
Content-Type et Content-Encoding). 

Une reponse HTTP 1.1 est composee de : 

• une ligne de statut qui precise la version du protocole HTTP utilise (en general HTTP 1 .0), un code 
reponse numerique et une description textuelle ; 

• zero ou plusieurs champs d' en-tetes du type « champ:valeur ». Les en-tetes sont de type general, 
reponse ou entite ; 

• une ligne vide ; 

• un corps de message MIME optionnel : la presence ou non de ce contenu depend de la commande 
utilisee. La forme de ce corps de message depend du type et de l'encodage utilise (champs 
Content-Type et Content-Encoding). 

L indication de la version de protocole utilisee est tres importante car elle permet la prise en compte 
d' intermediaries sur le reseau qui ne prennent pas tous en charge les memes versions : la version 1.1 
assure une compatibilite ascendante avec la version 1 .0. 
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Tableau 5-1. Methodes predefines par le protocole HTTP 1.1 

Commande Description 

OPTIONS Demande d'informations. Cette commande accepte « * » comme URL, ce qui signifie que la ressource 

interrogee est le serveur lui-meme. 

GET Demande la restitution d'une entite (de donnees) identifier par I'URL. 

HEAD Equivalent a GET mis a part que le serveur ne doit pas retourner de corps de message. 

POST Envoi d'une entite (de donnees) a I'URL specifiee. II s'agit, par exemple, d'annoter une ressource ou de 

soumettre des donnees a un programme. La fonction exacte depend du serveur et de FURL. 

PUT Envoi d'une entite (de donnees) a I'URL specifiee : cette URL est I'adresse de I'entite envoyee (qui repre- 

sente une ressource a creer ou a modifier) et non celle d'une ressource de traitement comme c'est le cas 
pour POST. 

DELETE Suppression de la ressource situee a I'URL specifiee. 

TRACE Permet de visualiser le message exact recu par le serveur. 

CONNECT Reserve par les serveurs de type proxy pour etablir des connexions tunnel SSL. 

D'autres commandes peuvent etre implementees par les logiciels HTTP sous forme d' extension. A 
ce propos, il existe un « cadre » defini pour mettre en ceuvre ces extensions (An HTTP Extension 
Framework - RFC2774). 

L' exemple suivant ouvre une connexion Telnet sur le port 80 (port par defaut de HTTP) et utilise la 
commande OPTIONS pour connaitre les options du serveur. Si cette commande etait passee en HTTP 1.1, 
nous serions obliges de fournir le champ Host puisque c'est le seul champ obligatoire (dans le cas 
contraire, le serveur retournerait un code 400) : 

OPTIONS * HTTP/1.0 
HTTP/1.1 200 OK 

Date: Wed, 31 Jul 2002 09:33:50 GMT 

Server: Apache/1.3.26 (Unix) mod_ssl /2.8.9 OpenSSL/0.9.6d PHP/4.2.2 
Content-Length: 
Allow: GET. HEAD, OPTIONS, TRACE 
Connection: close 

Quelques remarques sur cet exemple : 

• la premiere ligne de reponse est le statut de la reponse ; 

• la date est celle a laquelle le serveur a genere la reponse ; 

• la ligne Server permet de connaitre les caracteristiques techniques du serveur ; 

• la reponse ne contient aucune entite (donnees) ; 

• le serveur accepte les commandes GET, HEAD, OPTIONS et TRACE ; 

• la connexion est fermee (non persistente) : la prochaine requete necessitera une nouvelle connexion. 
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Tableau 5-2. En-tetes HTTP de type general 

En-tete Description 

Cache-Control Definit les directives de gestion de cache qui doivent etre respectees par tous les acteurs de la 

chaine de requetes/reponses ; par exemple : Cache-Control: no-cache. 

Connecti on Permet d'indiquer si la connexion est persistante ou fermee apres chaque reponse ; par exemple : 

Connectiomclose. 

Date Date et heure a laquelle a ete genere le message. 

Pragma Directives specifiques. La valeur no-cache existe pour des raisons de compatibilite avec 

HTTP 1 .0. 

Trailer Permet d'indiquer les champs d'en-tetes qui seront presents dans le dernier message lors d'un 

transfert utilisant un codage morcele (Chunked). 

Transfer-Encoding Precise la methode d'encodage de I'entite. 

Upgrade Permet au client d'indiquer les protocoles qu'il prend en charge. Si le serveur choisit de changer de 

protocole, il repond par un code 101 en indiquant le protocole retenu ; par exemple : Upgrade: 
HTTP/1.1. 

V 1 a Utilise par les proxies et les passerelles pour indiquer les protocoles inter mediaires utilises entre le 

client et le serveur. 

Warm' ng Informations complementaires permettant d'avertir I'utilisateur sur des transformations de I'entite. 



Tableau 5-3. En-tetes HTTP de type requete 

En-tete Description 

Accept Type de contenu MIME accepte par le client (code 406 en cas d'erreur) ; par exemple : Accept: 

text/*, audio/basic. 

Accept-Charset Jeu de caracteres accepte par le client (code 406 en cas d'erreur) ; par exemple : Accept-Char- 

set: iso-8859-1. 

Accept-Encoding Codage de donnees accepte par le client (code 406 en cas d'erreur) ; par exemple : Accept- 

Encoding: compress, gzip. 

Accept- Language Langue naturelle accept.ee par le client (anglais par defaut) (code 406 en cas d'erreur) ; par exemple : 

Accept-Language: en-gb, fr. 

Authorization Identification du client aupres du serveur (code 401 en cas d'erreur). 

Expect Permet au client d'indiquer le comportement qu'il attend du serveur. 

From Contient I'adresse e-mail de I'utilisateur du client. 

Host Contient I'adresse du serveur et le port de la ressource demandee. Ce champ est obligatoire pour 

toute commande HTTP 1.1 (il est optionnel en 1 .0) ; par exemple : Host : www.eyrolles.com. 

If -Match La commande n'est executee que si I'entite associee a la ressource possede un tag equivalent a 

celui qui est fourni (sinon code 41 2). 

If-Modified-Since La commande n'est pas executee si I'entite associee a la ressource n'a pas ete modifiee depuis 

la date fournie (sinon code 304). 

If-None-Match La commande n'est pas executee si une entite associee a la ressource existe ou si une entite 

ayant un tag equivalent a celui qui est fourni existe (sinon code 412). 
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Tableau 5-3. En-tetes HTTP de type requete (suite) 

En-tete Description 

If-Range Ce champ doit etre utilise avec un champ Range. II prend comme valeur soit le tag de I'entite, soit 

sa date de derniere modification. Si le serveur possede une entite inchangee, il renvoie la portion 
specifiee, sinon il renvoie I'entite complete. 

If-Unmodified-Since Le serveur ne renvoie I'entite que si elle n'a pas ete modifiee depuis la date fournie (sinon code 
412). 

Max-Forwards Precise le nombre maximal de transmission qui peuvent etre executees par des proxies ou des 

relais dans le cadre d'une commande TRACE ou OPTIONS . 

Proxy-Authorization Identification du client aupres du proxy (code 407 en cas d'erreur). 

Range Determine une portion d'entite en octets ; par exemple, les cinq cents premiers octets : Range: 

bytes=0-499. 

Ref erer Permet au client d'indiquer I'adresse de la ressource depuis laquelle la requete est soumise . 

TE Indique les extensions d'encodage acceptees ; par exemple :TE: trailers. 

User-Agent Informations sur le client, comme le nom et la version du navigateur. 



Tableau 5-4. En-tetes HTTP de type reponse 



En-tete Description 

Accept-Range Permet au serveur d'indiquer les conditions de portee pour la ressource ; par exemple : Accept- 

Range: bytes. 

Age Indique le temps ecoule en secondes depuis la generation de la reponse par le serveur d'origine. 

ETag Definit un tag permettant d'identifier I'entite courante. Cette donnee pourra etre utilisee comme element 

de comparaison pour etablir si deux entites sont equivalentes (contrainte de cache) ; par exemple : 
ETag: "xyzu", "hjky". 

Locati on Adresse de la ressource que le client doit utiliser a la place de I'URI initial. 

Proxy-Authenticate Methode d'authentification utilisee par un proxy; par exemple : Proxy-Authenticate: Basic. 

Retry-After Permet d'indiquer une periode de temps apres laquelle le service est de nouveau disponible (code 

503) ou la redirection peut etre executee (code 3xx. 

Server Precise quel logiciel et quels sous-produits sont utilises pour generer la reponse . 

Vary Permet d'indiquer les champs d'en-tetes de requete qui deter minent si un cache peut utiliser la 

reponse pour de futures requetes sans validation du serveur. 

WWW-Authenticate Methode d'authentification utilisee par le serveur ; par exemple : WWW-Authenticate: Basic. 
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En-tete 

Al low 

Content-Encoding 

Content-Language 

Content-Length 

Content-Location 

Content-MD5 

Content-Range 

Content-Type 
Expi res 
Last-modified 



Tableau 5-5. En-tetes HTTP de type entite 

Description 

Liste les commandes acceptees pour cette ressource (code 405 en cas d'erreur) ; par exemple : Al 1 ow : 
GET, HEAD, PUT. 

Type d'encodage de I'entite (code 415 en cas d'erreur) ; par exemple : Content-Encoding: gzip. 

Langage naturel de I'entite ; par exemple : Content- Language: fr. 

Taille de I'entite en octets. 

Precise I'adresse de I'entite lorsque celle-ci est differente de I'adresse demandee . 

Code de controle d'integrite du message. 

Precise (en octets) la portion de I'entite envoyee lorsque celle-ci est partielle (code 416 en cas 
d'erreur) ; par exemple, les cinq cents premiers octets parmi un total de mille trois cents : Content- 
Range: bytes 0-499/1300. 

Type MIME de I'entite ; par exemple : Content-Type: text/html ; charset=IS0-8859-l. 

Precise la date et I'heure d'expiration de la reponse. 

Date de derniere modification de la ressource. 



Tableau 5-6. Principaux codes de retour HTTP 



Code 


Message 


Description 


10x 


Message d'information 


Requete recue, le traitement continue. 


101 


SWITCHING PROTOCOL 


Changement de protocole. 


20x 


Reussite 


L'action a ete correctement recue, comprise et acceptee. 


200 


OK 


La requete a ete accomplie correctement. 


201 


CREATED 


Elle suit une commande POST et indique la creation de la nouvelle res- 
source a I'URL indiquee. 


202 


ACCEPTED 


La requete a ete acceptee, mais la procedure qui suit n'a pas ete accomplie . 


203 


NON-AUTHORITATIVE INFORMATION 


Les meta-informations renvoyees ne sont pas celles du serveur d'origine 
mais proviennent d'une source tierce. 


204 


NO CONTENT 


Le serveur a regu la requete mais il n'a pas d'entite a renvoyer. Les en- 
tetes peuvent avoir ete mis a jour. 


205 


RESET CONTENT 


Le serveur indique au navigateur d'initialiser la page qui a initie la 
requete (les champs de formulaire). 


205 


PARTIAL CONTENT 


Le serveur a repondu partiellement a une requete GET (en-tete 
Content-Range). 


30x 


Redirection 


Des actions supplementaires doivent etre executees pour completer la 
requete. 


301 


MOVED PERMANENTLY 


La ressource demandee a ete transferee de maniere permanente vers 
une nouvelle URL. 


302 


FOUND 


La ressource demandee a ete transferee temporairement vers une 
nouvelle URL. 


303 
1 


SEE OTHER 


La reponse a la requete peut etre trouvee a une adresse differente et 
doit etre recuperee a I'aide de la commande GET. 
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Tableau 5-6. Principaux codes de retour HTTP (suite) 



Code 


Message 


Description 


304 


NOT MODIFIED 


Si le client a effectue une commande GET conditionnelle (en demandant 
si le document a ete modifie) et que la condition n'est pas remplie, le 
serveur ne renvoie pas de corps de message. 


305 


USE PROXY 


Lacces a la ressource demandee doit se faire a travers le proxy dont 
I'adresse est fournie. 


307 


TEMPORARY REDIRECT 


La ressource demandee a ete transferee temporairement vers une 
nouvelle URL. 


40x 


Erreur du client 


La requete est incorrecte. 


400 


BAD REQUEST 


La requete est mal formulee du fait d'une erreur de syntaxe. 


401 


UNAUTHORIZED 


Le client doit reformuler sa requete avec les donnees d'autorisation 
correctes. 


402 


PAYMENT REQUIRED 


(reserve) 


403 


FORBIDDEN 


Lacces a la ressource est interdit, independamment des parametres 
d'autorisation. 


404 


NOT FOUND 


Le serveur n'a rien trouve a I'adresse specifiee. 


405 


METHOD NOT ALLOWED 


La commande n'est pas acceptee pour la ressource specifiee. 


406 


NOT ACCEPTABLE 


Les en-tetes de type Accept- ne sont pas coherents avec la reponse. 


407 


PROXY AUTHENTICATION REQUIRED 


Similaire au code 401, a la difference pres que I'authentification 
concerne le proxy. 


408 


REQUEST TIMEOUT 


Le client n'a pas envoye sa requete dans le temps imparti par le serveur. 


409 


CONFLICT 


La requete n'a pas pu etre executee en raison d'un conflit avec I'etat 
courant de la ressource. 


410 


GONE 


La ressource n'est plus disponible sur le serveur et aucune redirection 
n'est connue. 


411 


LENGTH REQUIRED 


Len-tete Content- Length doit etre fourni. 


412 


PRECONDITION FAILED 


Les preconditions fournies dans I'en-tete ne sont pas remplies. 


413 


REQUEST ENTITY TOO LARGE 


Lentite specifiee depasse la capacite de traitement du serveur. 


414 


REQUEST-URI TOO LONG 


LURL specifiee depasse la capacite de traitement du serveur. 


415 


UNSUPPORTED MEDIA TYPE 


Le format specifie n'est pas reconnu par le serveur. 


416 


REQUESTED RANGE NOT SATISFIABLE 


Len-tete specifie une plage de valeurs (range) qui depassent celle de 
la ressource. 


417 


EXPECTATION FAILED 


Len-tete specifie des conditions (expect) qui ne peuvent etre satisfaites 
par le serveur. 


50x 


Erreur du serveur 


Le serveur a echoue dans le traitement de la requete. 


500 


INTERNAL ERROR 


Le serveur a rencontre une condition inattendue qui I'empeche de donner 
suite a la demande. 


501 


NOT IMPLEMENTED 


Le serveur ne prend pas en charge le service demande, necessaire 
pour satisfaire la demande. 
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Tableau 5-6. Principaux codes de retour HTTP (suite) 



Code 


Message 


Description 


502 


BAD GATEWAY 


Le serveur a regu une reponse invalide de la part du serveur auquel il 
essayait d'acceder en agissant comme une passerelle ou un proxy. 


503 


SERVICE UNAVAILABLE 


Le serveur ne peut pas repondre en raison d'une surcharge ou d'une 
maintenance. 


504 


GATEWAY TIMEOUT 


Le serveur, agissant comme passerelle ou proxy, n'a pas regu de 
reponse dans le temps imparti. 


505 


HTTP VERSION NOT SUPPORTED 


La version de HTTP specifiee n'est pas prise en charge. 



Ces codes de retour sont extensibles et a la charge des logiciels HTTP. 

Exemple de dialogue 

Si nous utilisons un programme « sniffer »' qui permet d' analyser les trames HTTP, nous pouvons 
suivre les requetes/reponses envoyees par un navigateur pour acceder a la page d'aide du site Internet 
d'Eyrolles (voir figure 5-2). 

La trame 20 (premiere colonne de gauche) est la suivante : 

GET /php.accueil/InfoDiverses/aide.php3 HTTP/1.1 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg. ... 

Referer: http://www.eyrolles.com 

Accept-Language: fr 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; windows NT 5.0; T312461) 

Host: www.eyrolles.com 

Connection: Keep-Alive 

Cookie: Xd=4a8fb479a88413cc99ba00c3038f6d73 

Elle nous indique qu'il s'agit d'une commande GET en HTTP 1.1 vers la page aide.php3 dont le 
chemin est donne en relatif. L'adresse complete peut-etre reconstitute a l'aide du champ Referer: 
http://www.eyrolles.com (voir le detail du message dans le panneau du milieu). Les autres champs 
nous donnent plusieurs indications : 

• Le navigateur est MS Internet Explorer 6 sous Windows 2000 (User-Agent). 

• Le navigateur est configure pour une audience francaise (Accept-Language), et prend en charge un 
certain nombre de formats de fichiers (Accept) : Gif, Bitmap, Jpeg, PowerPoint, Excel et Word. 

• La connexion est maintenue dans Fattente de la reponse (Connection: Keep-Alive). Ce mode de 
fonctionnement est un peu particulier puisqu'il utilise le mecanisme de connexion persistante de 
HTTP 1.0. En effet, en HTTP 1.1, toutes les connexions sont par defaut persistantes (sauf indication 
contraire) et Fen-tete Connecti on : Keep-Al i ve n'a done plus de signification. 



1. Par exemple, le produit Ethereal est gratuit et disponible a http://www.ethereal.com. 
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Figure 5-2 

Detail du dialogue HTTP navigateur/serveur pour Vacces a la page http://www.eyrolles.com/php.accueil/infodiverses/ 
aide.php3. 



La reponse du serveur est la trame 22 : 

HTTP/1.1 200 OK 

Date: Wed, 31 Jul 2002 09:33:50 GMT 

Server: Apache/1.3.26 (Unix) mod_ssl /2.8.9 0penSSL/0.9.6d PHP/4.2.2 

Expires: Thu. 19 Nov 1981 08:52:00 GMT 

Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0 

Pragma: no-cache 

Keep-Alive: timeout=15, max=100 

Connection: Keep-Alive 

Transfer-Encoding: chunked 

Content-Type: text/html 
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Nous pouvons faire deux remarques : 

• Les champs Expi res (1981 !), Cache-Control et Pragma indiquent tous que la page ne doit pas etre 
mise en cache. 

• La connexion est persistante (Keep-Al i ve), d'autant que le transfert est morcele (Transfer- Encoding: 
chunked), c'est-a-dire que le fichier est envoye en plusieurs trames, ce qui est un mode de fonction- 
nement courant. Labsence de champ Trailer indique que les trames suivantes n'auront aucun 
champ d'en-tete mais uniquement un corps de message. 

L entite de type HTML est renvoyee en plusieurs trames consecutives (23, 27, 28, 39, 41, 43 et 58) 
que le navigateur se charge d' assembler. Cette page HTML contient des references a des images mais 
pas leur contenu. Le navigateur interroge done le serveur pour recuperer ces fichiers de dependance 
(trames 36, 37, 47, etc.). 

La trame 36 est la suivante : 

GET /images/eyrolles_4_petit.gif HTTP/1.1 

Accept: */* 

Referer: http://www.eyro! les.com/php.accueil /infodi verses /a ide.php3 

Accept-Language: fr 

Accept-Encoding: gzip, deflate 

If-Modified-Since: Thu. 26 Jul 2001 13:54:41 GMT 

If-None-Match: "275b4-195d-"b602121" 

User-Agent: Mozilla/4.0 (compatible;MSIE 6.0;Windows NT 5.0; T312461) 

Host: www.eyrolles.com 

Connection: Keep-Alive 

Ce qui est interessant dans cette commande GET, e'est qu'il s'agit d'une commande soumise a une 
condition car le client dispose deja d'une entite issue de la meme ressource : le fichier en question a 
une date de derniere modification au 26/07/2001 a 13 h 54 et un ETag "275b4-195d-"b602121". 
Internet Explorer cherche a optimiser les transferts de donnees en utilisant son cache et en evitant de 
rapatrier des fichiers qu'il possede deja. 

La reponse du serveur est la trame 52 : 

HTTP/1.1 304 NOT MODIFIED 

Date: Wed, 31 Jul 2002 14:29:21 GMT 

Server: Apache/1.3.26 (Unix) mod_ssl /2.8.9 0penSSL/0.9.6d PHP/4.2.2 

Keep-Alive: timeout=15, max=100 

Connection: Keep-Alive 

ETag: "275b4-195d-"b602121" 

Elle signifie que cette entite (ce fichier image Gif) n'a pas ete modifiee depuis la derniere requete et 
qu'il n'est done pas necessaire de la renvoyer. 



SMTP 



SMTP (Simple Mail Transfer Protocol) est un standard Internet (Proposed Standard) propose par 
1TETF sous la reference RFC2821 (derniere RFC de avril 1996). 
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Cette specification a pour objectif de definir un protocole application (couche 7, voir en annexe la 
section « Le modele de reference OSI de 1'ISO ») de transfert de courrier electronique (e-mail) en 
utilisant un canal de distribution tel que TCP (mais non limite a ce canal). Sa simplicite explique sans 
doute sa robustesse, il est par ailleurs tres largement utilise aujourd'hui pour la messagerie Internet, 
associe a POP ou IMAP4 : SMTP se charge du transfert des messages alors que POP (Post Office 
Protocol) ou IMAP (Internet Mail Access Protocol) permettent a l'utilisateur de gerer sa boite aux 
lettres et de recuperer ses messages. 

Une fonction importante de SMTP est la possibilite de transferer un message en s'appuyant sur un 
reseau de serveurs relais et de garantir ainsi sa livraison a travers des environnements de transport 
differents : LAN, WAN, Internet, etc. 

Transmission d'un message 

Le transfert d'un message se passe de la maniere suivante : 

• Un client SMTP (tel que MS Outlook Express ou Mozilla), appele aussi emetteur ou MUA (Mail 
User Agent), envoie un message vers un serveur SMTP. 

• Si le serveur SMTP en question est le destinataire final du message, il stocke ce message dans la 
boite aux lettres de l'utilisateur. Souvent, un serveur SMTP est aussi appele MTA (Mail Transfert 
Agent). 

• Mais si le serveur SMTP n'est pas ce destinataire final, on parle d'un serveur relais, puisqu'il se 
charge de transmettre ce message au serveur de destination finale. Un tel serveur est appele egalement 
passerelle {gateway) lorsque le transfert se fait entre deux environnements de transport differents. 

II est important de comprendre qu'un meme serveur SMTP peut-etre amene a jouer le role de 
destinataire final (stockage des messages), d'emetteur et de relais (ou de passerelle). 

Un message est toujours envoye a un destinataire qui est identifie par une adresse du type partie-locale 
@domaine. C'est le nom de domaine de 1' adresse qui permet a un serveur emetteur, et aux serveurs 
relais, de determiner le serveur destinataire du message grace a un mecanisme de resolution de noms 
de domaine (« DNS lookup ») : chaque nom de domaine possede dans les serveurs DNS un enregis- 
trement MX (Mail eXchanger) qui identifie le serveur SMTP responsable de la gestion des messages 
de ce domaine (ou une passerelle dans des situations plus complexes). 

A noter enfin que chaque serveur est responsable de la transmission d'un message et, en cas d'erreur 
ou de probleme, de la notification du probleme a l'emetteur. 

Description du message 

SMTP transporte un objet message compose : 

• d'une enveloppe, elle-meme composee d'une serie de champs, dont l'adresse de l'emetteur, une ou 
plusieurs adresses de destinataires et des donnees d'extension ; 

• d'un contenu, compose d'un en-tete et d'un corps de message MIME. 

La specification SMTP ne decrit pas la syntaxe du message qui fait l'objet d'une RFC independante 
(RFC2822), associee bien sur a celle de MIME. 
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Commandes SMTP 



Le transfert des messages est realise lors d'un dialogue entre deux serveurs SMTP : respectivement 
le client qui emet le message (qui peut etre la source du message ou un relais) et le serveur qui le 
receptionne (qui peut etre le destinataire du message ou un relais). 

Ce dialogue s'etablit dans le cadre d'une session. Le client envoie ensuite une sequence de commandes 
qui attendent systematiquement une reponse du serveur pour notifier du succes ou de l'echec de la 
commande (par exemple : 250 OK). 

Une sequence type est la suivante 1 : 

1. La commande EHLO (ou HELO) initie le dialogue, identifie le client et lui permet de connaitre les 
extensions SMTP supportees par le serveur. 

2. La commande MAIL FROM debute une transaction d'envoi de message en precisant l'adresse de 
l'emetteur. 

3. La commande RCPT TO identifie l'(les)adresse(s) des destinataires. 

4. La commande DATA envoie, ligne a ligne, le contenu du message. La fin de la transmission et done 
de la transaction est indiquee par une ligne contenant uniquement un caractere « . ». Seuls les 
messages transmis dans le cadre d'une transaction valide et complete seront traites par le serveur. 

5. La commande QUIT termine la session. 
Par exemple : 

220 mel-rtalO. wanadoo.fr ESMTP Service (6.5.007) ready 
EHLO www.mondomaine.com 

250-mel -rtalO.wanadoo.fr 

250-DSN 

250-8BITMIME 

250-PIPELINING 

250-HELP 

250-ETRN 

250 SIZE 10240000 
MAIL FROM :<monad res se@mondomaine.com> 

250 MAIL FROM<monadresse@mondomaine.com> OK 
RCPT TO:<tonadresse@tondomaine.com> 

250 RCPT TO:<tonadresse@tondomaine.com> OK 
DATA 

354 Start mail input;end with <CRLF>.<CRLF> 
Bonjour, 
Ceci est mon mail . 

250 Mail accepted 
QUIT 

221 mel-rtalO. wanadoo.fr QUIT 



1 . II est possible de tester ces commandes et done d'envoyer un e-mail a l'aide de Telnet sur le port 25 d'un MTA. 
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D'autres commandes sont definies par SMTP : 

• RESET, qui arrete la transaction en cours ; 

• VERI FY, qui verifie 1' argument comme etant une adresse de messagerie ; 

• EXPAND, qui verifie que l'argument est une liste de messagerie et retourne le contenu de cette liste ; 

• HELP, qui demande une information ; 

• NOOP, qui n'a aucune action si ce n'est une reponse du serveur. 

Enfin, des extensions SMTP sont possibles : il s'agit de commandes commencant par un caractere 
« X » et qui dependent des logiciels serveurs SMTP utilises. La commande EHLO permet de connaitre 
ces extensions. 



Les protocoles SSL etTLS 

SSL (Secure Socket Layer) est un protocole qui a pour objectif d' assurer la securite des echanges 
entre un client et un serveur sur le Web (authentification et chiffrement). II a ete developpe par la 
societe Netscape qui a d'ailleurs depose un brevet sur cette technologie en 1997 (n°5657390), meme 
si elle n'a jamais demande de contrepartie nnanciere. La version 2.0 de SSL date de 1994 (http:// 
wp.netscape.com/eng/security/SSL_2.html) : cette version est obsolete, mais elle est pourtant toujours prise 
en charge par les principaux navigateurs. En 1996, un groupe de travail est cree par 1TETF afin de 
standardiser un protocole de securite pour remplacer SSL. Cette date coincide avec la publication 
de la version 3.0 de SSL (Internet Draft disponible a http://wp.netscape.com/eng/ssl3), qui est par ailleurs 
la version la plus recente de ce protocole. Enfin, le groupe de travail de 1TETF a publie en 1999, sous la 
reference RFC2246 (Proposed Standard), la version 1.0 de TLS (Transport Layer Protocol). Les 
differences entre SSL v3 et TLS vl sont mineures et d'ailleurs ce dernier s'identifie lui-meme comme 
la version 3.01 de SSL. 

Les principaux navigateurs Internet prennent en charge les trois protocoles : SSL v2, SSL v3 etTLS vl. 
Mais contrairement a Netscape Navigator et Mozilla, Internet Explorer n' active pas par defaut TLS, 
qu'il faut done configurer manuellement. Lorsqu'un navigateur negocie une connexion securisee 
avec un serveur, il cherche d'abord a etablir une session TLS, puis dans l'ordre une session SSL v3 et 
une session SSL v2, en fonction des possibilites du serveur. 

Introduction a la securite 

Les techniques mises en ceuvre pour assurer la securite des echanges ont pour objectif : 

• pour l'emetteur, de crypter ses donnees et pour le recepteur, de les decrypter ; 

• de controler l'integrite des informations recues ; 

• d'authentifier l'emetteur du message ; 

• d'obliger l'emetteur a reconnaitre remission des informations grace a un mecanisme de non- 
repudiation. 
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Le chiffrement/dechiffrement de Finformation est realise a l'aide d'un algorithme (ou cipher en 
anglais) : l'interet de cette technique est que la sflrete du chiffrement ne repose pas sur la methode de 
calcul utilisee, qui est connue et publiee, mais sur F utilisation de chiffres, appeles cles, qui permettent 
a 1' algorithme de generer un document crypte, puis de le decrypter. Plus ces cles sont grandes (en 
nombre de bits), plus il est difficile, voire « impossible », de decrypter un document si Ton ne connait 
pas les chiffres qui ont permis sa generation. 

Deux types de cles sont utilises : 

• Les cles symetriques : comme leur nom Findique, la meme cle est utilisee pour crypter et decrypter 
les donnees. Cette technique est rapide et fournit en outre un moyen d'authentification. Elle est 
neanmoins un peu sensible, puisque toute la securite repose sur la connaissance d'une cle que 
l'emetteur et le recepteur doivent garder secrete. 

• Les cles publiques (ou asymetriques) : le principe consiste a crypter les donnees avec une cle 
publique, c'est-a-dire connue de tout le monde, et de les decrypter avec une cle privee connue 
uniquement par le recepteur. Les deux cles publique/privee fonctionnent par paire et dans les deux 
sens puisque, a Finverse, la cle publique peut decrypter ce qui a ete genere a l'aide de la cle privee. 
Cette technique est plus lourde et n'offre pas de mecanisme d'authentification de l'emetteur. En 
revanche, elle permet d'authentifier le recepteur qui peut crypter sa signature a l'aide de sa cle privee. 

Le controle d'integrite d'un message est realise a partir d'une signature electronique, elle-meme 
cryptee, et qui est le resultat d'une fonction de hachage. 

Une fonction de hachage appliquee a des donnees fournit un chiffre unique : la moindre alteration de 
ces donnees modifie obligatoirement le resultat du hachage. 

Le resultat d'une fonction de hachage ne permet pas de determiner les donnees qui ont permis sa 
generation. 

Un certificat est un document electronique qui permet d'identifier une entite, c'est-a-dire un utilisateur, 
une entreprise, un serveur, etc. II est associe a la cle publique de l'entite qu'il identifie. II est egalement 
lie a une autorite de certification (CA ou Certification Authority) : il s'agit d'une application serveur 
qui peut etre specifique a une entreprise, ou geree par une organisation tierce (telle que Verisign : http:/ 
/www.verisign.com). Le role de cette autorite est de generer le certificat et de proposer a l'utilisateur qui 
le recoit une fonction de validation. 

Les certificats, associes aux signatures electroniques, sont utilises pour authentifier a la fois le client 
et le serveur dans le cadre d'une connexion SSL, mais aussi des e-mails (S/MIME), du code Java ou 
JavaScript, etc. 

Presentation generate 

SSL et TLS sont des protocoles qui se situent a un niveau intermediate, entre la couche transport et 
la couche application. Cette position permet done a priori a toutes les applications qui s'appuient sur 
TCP/IP (HTTP, SMTP, Telnet, etc.) d'utiliser les fonctionnalites de SSL/TLS, soit : 

• permettre a un serveur de s' authentifier aupres d'un client, c'est-a-dire au client de verifier l'identite 
du serveur ; 
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• optionnellement, permettre au client de s'authentifier aupres du serveur, c'est-a-dire au serveur de 
verifier Fidentite du client ; 

• permettre au client et au serveur de selectionner un algorithme de chiffrement ; 

• permettre aux deux machines d'etablir une connexion cryptee pour assurer un haut niveau de 
confidentialite. 

Ces protocoles sont decomposes en deux sous-protocoles : 

• le protocole d'enregistrement (record protocol), qui definit le format de transmission des donnees ; 

• le protocole de negociation (handshake protocol), qui s'appuie sur le protocole d'enregistrement, 
et qui est charge d'etablir la connexion entre le client et le serveur (authentification, selection de la 
methode de chiffrement, etc.). 

Les methodes de chiffrement (cipher) 

Tous les echanges de donnees realises dans le cadre d'une connexion SSL/TLS, y compris les messages 
initiaux geres par le protocole de negociation, sont cryptes. Differents algorithmes mathematiques, 
classes en suites de chiffrement, sont pris en charge par SSL/TLS. Ces algorithmes sont tres nombreux 
mais les principaux sont les suivants : 

• DES (Data Encryption Standard), un algorithme de chiffrement a base de cles symetriques cree par 
IBM en 1977 et utilise par le gouvernement americain avant AES (FTPS 46-3, ANSI X3.92 et X3. 106) ; 

• Triple-DES, 1' algorithme DES applique trois fois ; 

• AES (Advanced Encryption Standard) est le nom du projet lance en 1997 par le NIST pour trouver 
un remplacant a DES. En octobre 2000, l'algorithme de chiffrement a base de cles symetriques 
Rijndael, cree par Joan Daemen et Vincent Rijmen, a ete retenu et est devenu un standard federal 
americain (FIPS 197) ; 

• IDEA (International Data Encryption Algorithm), un algorithme de chiffrement a base de cles 
symetriques, cree par Xuejia Lai et James Massey et considere comme tres efficace (brevet 
international detenu par la societe Ascom-Tech) ; 

• MD5 (Message Digest), un algorithme d'empreinte numerique developpe en 1991 par le professeur 
Ronald Rivest du MIT (RFC 1321) ; 

• RC2 et RC4 (Ron's Code), qui sont des algorithmes de chiffrement developpes par le professeur 
Ronald Rivest du MIT pour la societe RSA Security (brevet international) ; 

• RSA, qui est un algorithme a base de cle publique developpe en 1977 par Rivest, Shamir et 
Adleman. II est utilise a la fois pour le chiffrement et F authentification. (brevet US n° 4405829, 
tombe dans le domaine public depuis septembre 2000) ; 

• SHA-1 (Secure Hash Algorithm), un algorithme d'empreinte numerique developpe en 1994 et 
utilise par le gouvernement americain ; 

• SKIPJACK, un algorithme a base de cle symetrique implemente dans des systemes materiels 
compatibles FORTEZZA (tels que la puce Clipper) et utilise par le gouvernement americain (voir 
http://www. ietf. org/proceedings/99nov/l-D/draft-ietf-ipsec-skipjack-cbc-00. txf) . 
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Projet Capstone 

II est souvent fait allusion a I'usage de ces algorithmes par le gouvernement americain, car en 1987, un projet du 
nom de « Capstone » fut lance aux Etats-Unis afin de travailler autour des problemes de securite de llnformation 
(chiffrement, etc.). Ce projet est a I'origine de la creation de deux organisations connues dans ce domaine : la NSA 
(National Security Agency) et le NIST (National Institute of Standards and Technology) connu egalement sous le 
nom de NBS (National Bureau of Standards). Ces organismes poursuivent depuis leurs travaux et influencent en 
grande partie les evolutions technologiques en matiere de securite. 



Deux algorithmes sont utilises pour determiner les cles qui seront utilisees lors de F echange de donnees : 

• KEA (Key Exchange Algorithm), un algorithme utilise par le gouvernement americain ; 

• RSA Key Exchange (le plus utilise), un algorithme base sur 1' algorithme RSA. 

L' usage de telle ou telle suite de chiffrement depend de la configuration du client et du serveur : en fonc- 
tion des suites disponibles, ils chercheront systematiquement a utiliser la methode la plus puissante. 

Tableau 5-7. Suites de chiffrement utilisant lalgorithme RSA Key Exchange 



Suite de chiffrement 


Description 


Niveau 




Compatibility 


Triple DES (cle de 168 bits) et authentifi cation 
SHA-1 


Moins rapide que RC4 
mais tres puissant 


Tres eleve 




SSL v2, v3, TLS 


RC4 (cle de 128 bits) et authentification MD5 


Methode rapide 


Eleve 




SSL v2, v3, TLS 


RC2 (cle de 128 bits) et authentification MD5 


Moins rapide que RC4 


Eleve 




SSLv2 


RC4 (cle de 56 bits) et authentification SHA-1 




Eleve 




SSL v3 et TLS 


DES (cle de 56 bits) et authentification SHA-1 


Moins rapide que RC4 


Eleve 




SSLv2etv3,TLS 


RC4 (cle de 40 bits) et authentification MD5 


Methode rapide 


Autorise a 


'export 


SSLv2etv3,TLS 


RC2 (cle de 40 bits) et authentification MD5 


Moins rapide que RC4 


Autorise a 


'export 


SSLv2etv3,TLS 


Pas de chiffrement et authentification MD5 




Faible 




SSLv2etv3,TLS 
I 



Tableau 5-8. Suites de chiffrement utilisant lalgorithme KEA ou Key Exchange Algorithm 
(usage interdit en dehors du territoire des Etats-Unis) 



Suite de chiffrement 


Description 


Niveau 


Compatibilite 


RC4 (cle de 128 bits) et authentification SHA-1 


Methode rapide 


Eleve 


SSLv3 


RC4 (cle de 80 bits SKIPJACK) et authentification SHA-1 


Methode rapide 


Eleve 


SSLv3 


Pas de chiffrement et authentification SHA-1 




Faible 


SSLv3 



Le protocole de negotiation (handshake) 

Le protocole de negotiation correspond a un echange de messages realise entre le serveur et le client 
lors de Fouverture d'une session SSL/TLS. Cet echange est primordial puisqu'il permet au serveur 
de s' identifier grace aux techniques de cles privees (1' identification du client est optionnelle), de fixer 
les parametres de la session et de definir les cles symetriques qui seront utilisees pour le chiffrement/ 
dechiffrement. 
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II peut se resumer ainsi : 

• Le client envoie au serveur sa version SSL/TLS, ses parametres de chiffrement et toutes les donnees 
necessaires a Fetablissement de la session. 

• En retour, le serveur envoie sa version SSL/TLS et ses parametres de chiffrement ainsi que son 
certificat. Si cela est necessaire, il demande au client son certificat pour pouvoir Fauthentifier. 

• Le client procede aux tests d'authentification : date de validite, controle de Fautorite de certification, 
controle de la cle publique, etc. La validite de ces tests determine si la session peut se poursuivre 
ou non. 

• Le client cree la cle preliminaire (premaster), la crypte a Faide de la cle publique du serveur et la 
lui transmet. Si le serveur demande F identification du client, le client lui envoie aussi son certificat. 

• Le serveur decrypte les donnees transmises par le client, notamment la cle preliminaire, a Faide de 
sa cle privee. Si cela est necessaire, le serveur procede aux tests d'authentification : date de vali- 
dite, controle de Fautorite de certification, controle de la cle publique, etc. La validite de ces tests 
determine si la session peut se poursuivre ou non. 

• Le client et le serveur calculent Fun et Fautre une cle principale {master) a Faide de la cle preliminaire. 
Cette cle principale est utilisee pour calculer les deux cles de sessions symetriques : il y a une cle 
pour chaque sens de transmission, qui est utilisee a la fois pour crypter et decrypter les donnees 
transferees. 

• Les deux parties s'informent mutuellement de la fin des operations et mettent fin au protocole de 
negotiation. 



Annexe 

Le modele de reference OSI de I'lSO 

Un modele en 7 couches 

La norme internationale OSI (Open System Interconnection - ISO/IEC 7498) etablie par 1TSO a pour 
but de permettre F interconnexion de reseaux heterogenes. Le premier objectif de cette norme est de 
definir un modele theorique d' architecture valable pour tous les reseaux et base sur un decoupage en 
7 couches (voir tableau 5-8). 



Tableau 5-9. Les sept couches du modeles OSI. 


7 


Application 


Couches hautes 


6 


Presentation 




5 


Session 




[1 


Transport 


Couches basses 


3 


Reseau 




ri 


Liaison 




1 
i 


Physique 
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Chaque couche doit fournir un service via une interface a la couche situee au-dessus en lui epargnant 
les details d'implementation. Les fonctions decrites pour chaque couche ne sont pas toujours 
implementees de maniere stricte ou peuvent etre prises en charge par plusieurs couches. 

Meme si ce modele est une reference, il souffre de la concurrence du modele impose de facto par 
TCP/IP : ce dernier est certes tres proche mais il est aussi plus simple, et il est surtout le modele du 
protocole le plus utilise au monde grace a Internet. 

La couche physique C1 

La couche physique (ISO/IEC 10022) definit : 

• les moyens mecaniques et electriques : connecteurs, topologie (bus, anneau, etoile), la nature et les 
caracteristiques des supports (paire torsadee, cable coaxial, fibre optique, hertzien...), etc. ; 

• les caracteristiques de la transmission : modulation, portee, puissance en bauds ou en bits, les sens 
de transmission (simplex, half-duplex ou full-duplex), etc. ; 

• les procedures necessaires a F activation, au maintien et a la desactivation de la connexion. 
L unite d' information est le bit. 

Cette couche est done du res sort de Felectronique. 

La couche liaison C2 

La couche liaison (ISO/IEC 8886) definit : 

• les fonctions de detection et de correction d'erreurs ; 

• la structure syntaxique des messages en ajoutant aux donnees des informations de controle (adresse 
destination + adresse source + controle d'erreur) ; 

• la fonction de controle de flux. 

La couche liaison est decoupee en deux sous-couches : 

• MAC (Medium Access Control), qui gere les methodes d'acces au canal et qui est done dependante 
de la couche physique ; 

• LLC (Logical Link Control), qui assure Findependance de la couche reseau vis-a-vis des differentes 
implementations MAC (couche physique). 

L unite d' information est la frame. 

Plusieurs protocoles tres connus fonctionnent au niveau de cette couche : Ethernet, Token Ring mais 
aussi ATM ou PPP 



MAC est egalement utilise comme acronyme pour designer les adresses des cartes d'interface reseau (Media 
Access Card) codees sur 4 bits et uniques au monde. 



La couche reseau C3 

La couche reseau (ISO/IEC 8348) definit trois fonctions : 

• Fadressage, qui permet d'identifier le reseau et les machines du reseau 
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• le routage, qui consiste a determiner les nceuds intermediaries les plus adaptes pour acheminer les 
paquets a destination (a partir de tables de routage). Ce routage est realise de proche en proche et 
non de maniere globale ; 

• le controle de flux, qui assure la performance de la transmission en evitant la congestion du reseau. 

L'unite d'information est \epaquet. 

II existe deux possibilites d' implementation : en mode connecte, comme X25 ou IPX (Novell), et en 
mode deconnecte, comme IP. Le mode connecte necessite l'etablissement d'un circuit virtuel entre le 
nceud de depart et celui d'arrivee (une negotiation prealable a l'envoi) alors que le mode deconnecte 
envoie les paquets sans aucune garantie quant a leur reception par le destinataire. Le mode connecte est 
plus fiable mais il est beaucoup plus bavard et done plus lent. 

La couche transport C4 

La couche transport (ISO/IEC 8072) est particuliere dans le sens oil elle assure 1' interface entre les 
couches basses et les couches hautes de traitement. Son role est de rendre F utilisation du reseau 
transparente a Futilisateur et en particulier de combler l'ecart existant entre les services offerts par les 
couches basses et les services a offrir (requis). 

Cinq classes de procedures de transport, notees TPO a TP4, ont done ete definies pour permettre 
cette adaptation entre le niveau de la couche reseau (note selon trois valeurs : prefere, acceptable et 
inacceptable) et le besoin des applications. 

La couche transport definit done : 

• la notion de qualite de service (QoS) ; 

• la fonction d'exploitation des services de reseau disponibles pour un transport de bout en bout : 
identification, selection, ouverture et liberation de la (ou des) connexion(s) ; 

• la fonction de fragmentation et de reassemblage des donnees de la couche session ; 

• la fonction de multiplexage (et de demultiplexage). 
L'unite d'information est le message. 

Les protocoles de transport les plus connus sont TCP, UDP ou SPX (Novell). 

La couche session C5 

La couche session (ISO/IEC 8326) definit : 

• 1' organisation du dialogue entre applications (1' orchestration du « droit a la parole ») ; 

• la synchronisation des echanges ; 

• la gestion des points de reprise sur panne. 
L'unite d'information est parfois appelee transaction. 

La couche presentation C6 

La couche presentation (ISO/IEC 8822) definit : 

• la gestion syntaxique et semantique des informations transporters : ces informations peuvent etre 
representees dans une syntaxe abstraite telle que ASN. 1 (ISO/IEC 8824), independante des systemes 
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(differences entre processeurs Motorola 68000 et Intel x86, ou codage ASCII et EBCDIC, etc.) ; 
cette gestion permet d' assurer l'homogeneite des applications entre des systemes heterogenes ; 

• les services de preconditionnement et de postconditionnement des donnees, a savoir le chiffrement, 
la compression, etc. 

La couche application C7 

La couche application (ISO/IEC 9545) donne aux processus d' application le moyen d'acceder a 
l'environnement OSI en fournissant tous les services necessaires, a savoir : 

• le transfert d'informations ; 

• F allocation de ressources ; 

• le controle d'integrite des donnees ; 

• la synchronisation des applications cooperantes. 

Des exemples connus d' implementation sont HTTP, SMTP, FTP ou encore Telnet. 

Le modele d'architecture reseau TCP/IP 

Tableau 5-10. Comparaison des couches du modele OSI et du modele TCP/IP 





Modele TCP/IP 


Modele OSI 




7 


Application 
(Telnet, FTP, etc.) 


Application 


Couches hautes 


6 




Presentation 




5 




Session 




4 


Transport 
(TCP, UDP, etc.) 


Transport 


Couches basses 


3 


Reseau 

(IP, ARP, ICMR etc.) 


Reseau 




2 


Interface reseau 
(Ethernet, FDDI, etc.) 


Liaison 




1 Physique 



Contrairement au modele OSI, le modele TCP/IP, appele aussi modele Internet, n'est pas un modele 
theorique general et il a done le defaut de ne bien decrire que lui-meme et les implementations realisees 
sur TCP et/ou IP. 

Ce modele possede quatre couches (voir tableau 5-10 ) : 

• La couche & interface reseau est constituee a la fois d'un gestionnaire {driver) du systeme 
d' exploitation et d'une carte d'interface avec le reseau, e'est-a-dire a la fois de moyens mecaniques 
et electriques et de procedures de traitement. La definition de cette couche est peu contraignante, 
ce qui a permis de developper de nombreuses implementations : Ethernet (RFC894), X25 (RFC877), 
PPP (RFC1353), etc. L unite d'information est la trame. 
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• La couche reseau ou couche internet (avec un « i » minuscule) est equivalente a celle definie par 
le modele OSI : elle assure principalement les fonctions d'adressage et de routage. L' unite d' infor- 
mation est le datagramme. Plusieurs protocoles implementent cette couche : 

- IP est bien entendu le principal. 

- ARP (Address Resolution Protocol, RFC826) permet de connaitre Fadresse physique MAC 
d'une carte reseau associee a une adresse logique IP. C'est un mecanisme essentiel pour le 
fonctionnement du reseau, puisque l'etablissement des tables de correspondance entre les 
adresses physiques et logiques est un prealable a toute transmission. 

- RARP (Reverse Address Resolution Protocol, RFC903, a Finverse de ARP, permet de connaitre 
une adresse logique IP a partir d'une adresse physique MAC. Ce protocole est utilise par des 
stations de travail sans disques durs (par exemple un terminal X). 

- ICMP (Internet Control Message Protocol, RFC792) est un protocole qui est specialise dans la 
transmission de messages d'erreur : il s'agit en effet d'un protocole reseau bien qu'il s'appuie 
lui-meme sur IP. II est utilise par les routeurs pour avertir la couche transport d'une erreur de 
traitement d'un datagramme. 

• La couche transport est egalement equivalente a celle du modele OSI : elle assure une communi- 
cation de bout en bout sans s'occuper des intermediaries entre l'emetteur et le destinataire. Elle se 
charge de la regulation du flux, du decoupage et de l'ordonnancement des donnees ainsi que de la 
gestion des erreurs. II existe deux implementations principales de cette couche : 

- TCP (Transmission Control Protocol), qui est un protocole oriente connexion et fiable (sans 
erreur). L'unite d'information est le segment ; 

- UDP (User Datagram Protocol), qui est un protocole sans connexion mais non fiable. En effet, 
il ne gere ni la reprise sur erreur, ni l'ordonnancement des paquets, ni le controle de flux ou la 
gestion des accuses de reception. Les avantages d'UDP resident dans sa simplicite et sa rapi- 
dite, la fiabilite devant etre assuree par le reseau physique lui-meme (ce qui est envisageable 
dans le cas d'un LAN). L'unite d'information est le datagramme. 

• La couche application est assez equivalente a celle du modele OSI mais elle est situee immediatement 
apres la couche transport (absence des couches presentation et session). Cette couche est imple- 
mentee par des protocoles de haut niveau tels que FTP, HTTP, SMTP, etc. L'unite d'information est 
le message. 

Lorsqu'une information est transmise par une application, les donnees traversent chaque couche de 
haut en bas (de la couche application a la couche physique). Celles-ci ajoutent au passage des 
donnees supplemental s qui leur sont specifiques sous forme d'en-tetes (ou de remorques). Ce 
mecanisme est appele encapsulation. Ainsi, une trame Ethernet encapsule un datagramme IP qui 
encapsule un segment TCP qui encapsule le message de 1' application. 
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Figure 5-3 

Exemple d' encapsulation des couches d'une trame Ethernet. 



La couche transport met en relation differentes applications qui ont besoin d'etre identifiers les unes 
par rapport aux autres de facon a transmettre les messages aux bons programmes (demultiplexage). 
Cette identification est realisee a partir d'identifiants appeles numeros de ports (codes sur 16 bits). La 
combinaison d'une adresse IP et d'un port est appelee une socket. La combinaison de deux sockets 
definit completement une connexion TCP ou UDP puisqu'elle permet de connaitre les adresses logiques 
des machines source et destination ainsi que les ports sur lesquels les applications dialoguent entre 
elles. 



pour 



II existe trois types de numeros de port : 

• les numeros d' applications systeme (appele well-known) compris entre et 1023, comme 23 
Telnet ou 80 pour HTTP ; 

• les numeros d'application serveur (appele registered) compris entre 1024 et 49151, par exemple 
4000 pour ICQ et 26000 pour Quake ; 

• les numeros prives ou dynamiques compris entre 49152 et 65535. 

Les deux premieres categories concernent des numeros orficiels enregistres et geres par 1'IA.NA (voir 
la section « Definition de termes et organisation de la communaute Internet »). Ces numeros sont 
references par une application cliente emettrice pour identifier l'application a laquelle elle s'adresse 
sur le serveur : par exemple un serveur HTTP peut etre interroge (il « ecoute ») sur le port 80. En 
echange, l'application emettrice (le navigateur Internet) fournit le port sur lequel on pourra lui repondre : 
il s'agit alors d'un numero superieur a 1023 que l'application selectionne parmi les ports disponibles 
sur la machine (par exemple, le port 1330, comme le montre la figure 5-2). Ces numeros peuvent 
egalement etre utilises pour des applications serveurs dans le cadre d'un usage prive ; par exemple 
pour creer un serveur HTTP de test qui ecoute sur le port 8080. Dans ce cas, il est necessaire d'indiquer 
explicitement au navigateur Internet de se brancher sur ce port puisque, par defaut, une requete HTTP 
est dirigee vers le port 80. 
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Les specifications de standards Internet (RFC) 

Certains standards technologiques fondamentaux d'Internet, tels que MIME ou SMTP, sont geres par 
1'IETF et plus precisement par 1TESG et 1TAB (voir la section « Definition de teraies et organisation 
de la communaute Internet »). 

Toute specification d'un standard Internet et chacune de ses versions est publiee dans un document 
RFC (Request For Comments) : ces documents, introduits en 1969 par ARPANET, constituent le 
circuit de publication officiel de la communaute Internet. Les RFC ne traitent pas seulement de la 
definition des standards, ils traitent egalement de memos de travail ou de sujets de discussion varies 
ayant un rapport avec Internet. La publication de ces documents est geree par le RFC-Editor sous la 
direction de 1TAB. 

Le statut des specifications standards Internet est resume regulierement dans un RFC intitule « Internet 
Official Protocol Standards ». Le statut de depart est Internet Draft et certaines specifications attei- 
gnent le statut de standard, ce qui leur vaut d'obtenir un label supplementaire « STDxxxx » en plus 
de la denomination « RFCxxxx ». II existe plusieurs niveaux de maturite pour une specification standard 
qui sont dans l'ordre : Proposed Standard, Draft Standard puis Internet Standard. L evolution du 
statut et du niveau d'une specification est du ressort de 1'IESG. 

Evidemment, ces standards Internet peuvent s'appuyer a leur tour sur des standards definis par d'autres 
organismes tels que 1TSO ou l'ANSI. 

Definition de termes et organisation de la communaute Internet 

• ETSI : le European Telecommunications Standards Institute est une organisation a but non lucratif, 
chargee de definir les standards des telecommunication pour l'Europe (http://www.etsi.org). 

• IANA : lTnternet Assigned Numbers Authority est l'organisation qui a precede 1TCANN (http:// 
www.iana.org). 

• ICANN : lTnternet Corporation for Assigned Names and Numbers est une organisation a but non 
lucratif qui est responsable de F allocation des espaces d'adresses IP, de la definition des parametres 
de protocole, du systeme de gestion des noms de domaine et du systeme de gestion des serveurs 
racine (http://www.icann.org). 

• IAB : lTnternet Architecture Board est un groupe de 1TETF, charge de definir l'architecture 
globale d'Internet et les objectifs de 1'IETF. Les responsabilites de ce groupe sont tres importantes 
vis-a-vis de la communaute Internet (http://www.iab.org). 

• IESG : lTnternet Engineering Steering Group est un groupe de 1TETF, constitue des directeurs 
de services, charge avec 1TAB de la gestion de 1'IETF et de F approbation des standards (http://www 
.ietf.org/iesg.html). 

• IETF : lTnternet Engineering Task Force est une communaute internationale et ouverte de chercheurs, 
editeurs, ingenieurs, etc. qui travaillent a Fevolution et au fonctionnement d'Internet (http://www.ietf.org). 
Cette communaute est organisee en services correspondant a differents centres d'interets (routage, 
transport, securite, etc.). 
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IRTF : 1' Internet Research Task Force est une organisation chargee des travaux de recherche sur les 
protocoles, les applications, 1' architecture et les technologies Internet sous la tutelle de 1TAB 

(http://www. irtf. org) . 

ISOC : lTnternet Society est une organisation a but non lucratif qui a un role de direction et de 
coordination pour tout ce qui touche aux evolutions dTnternet, garantissant son ouverture, son 
fonctionnement et sa croissance (http://www.isoc.org). Ce role n'est rendu possible que parce que ces 
membres sont composes d'acteurs cle internationaux (des organisations a but non lucratifs, des 
entreprises, des fondations, des universites, des organisations gouvernementales) qui partagent un 
meme objectif de reussite. LTSOC est l'organisation mere de 1TETF, 1TRTF et 1TANA. 

RFC-editor : c'est un groupe fonde par 1TSOC et responsable de la publication, de Findexation et 
de la relecture finale des RFC (http://www.rfc-editor.org) 1 . 

W3C : le World Wide Web Consortium est une organisation dont l'objectif est de definir des 
technologies Internet (appelees recommandations) afin d' assurer revolution et l'interoperabilite 
du Web (http://www.w3.org). 



1. Des traductions francaises sont disponibles a http://www.rfc-editeur.org 
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XML 1.0 

XML (extensible Markup Language) est un format universel qui permet de structurer et d' organiser 
des documents et des donnees sur le Web. La version 1 .0 de cette recommandation a ete publiee par 
le W3C en fevrier 1998 et ce format est devenu depuis incontournable. Ce succes est bien sur lie au 
developpement d'Internet mais il tient aussi en grande partie aux objectifs initiaux que le groupe de 
travail s'etait fixe et qui tiennent en quelques mots : simple (a construire, a lire, a traiter), precis (pas 
d'ambiguite, regies syntaxiques strictes), universel (conforme a Unicode, independant de la plate- 
forme logicielle), extensible. 

XML est un sous -ensemble, une version simplifiee de SGML, et tout comme lui, c'est un langage a 
balises generique (markup language) : il etablit les regies syntaxiques servant a marquer un document 
et a en degager la structure mais il ne definit aucun jeu de balises (contrairement a HTML, par exemple). 
La definition de ces balises et de leur semantique appartient au concepteur qui construit le document. 

Rappel des regies de base 

Les regies syntaxiques d'XML sont simples mais strictes, ainsi, un programme qui traite un document 
XML doit s'arreter a la premiere erreur. 

On dit d'un document XML qu'il est bien forme s'il respecte les regies syntaxiques imposees et ainsi 
resumees : 

• Un document XML doit commencer par une ligne de declaration ne serait-ce que pour preciser la 
version d'XML. Exemple : 

<?xml version="1.0"?> 
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• Les elements qui composent un document XML doivent etre encadres par une balise ouvrante et 
une balise fermante. Exemple : 

<para> Ceci est un paragraphe </para> 

• Les noms de balises sont sensibles a la casse des caracteres. Exemple : 

1<Para> Ceci est correct </Para> 
<para> Ceci est incorrect </Para> 

• Tous les elements doivent etre correctement encadres entre eux. Exemple : 

|<para> <texte> Ceci est correct </texte> </para> 
<para> <texte> Ceci est incorrect </para> </texte> 

• Un document XML possede toujours une racine qui est definie par la premiere balise rencontree 
dans le traitement. Tous les elements du document sont encadres par cette racine. Exemple : 

<racine> 

<elementl> 
<souselementl> Sous element du premier element </sousel ementl> 

</el ementl> 

<element2> Second element </element2> 
</racine> 

• Les elements peuvent etre dotes d'attributs. Exemple : 

1<Para monattribut="mavaleur"> Element avec comme attribut monattribut de valeur 
mavaleur</Para> 

• Les valeurs des attributs doivent toujours etre encadrees par des quotes (simples ou doubles). 
Exemple : 

I<Para date="maintenant"> Ceci est correct </Para> 
<Para date=maintenant> Ceci est incorrect </Para> 

• Les commentaires sont definis par la balise < ! -- et -->. 

On dit d'un document qu'il est valide s'il respecte une certaine description : ces descriptions sont 
etablies par des DTD (Document Type Definition) ou des schemas (documents XML decrivant 
d'autres documents XML), internes ou externes. 

Un document XML 

Le corps d'un document XML est constitue d'un ou plusieurs elements delimites par des balises 
ouvrantes et fermantes. Ces elements sont organises entre eux dans une structure arborescente. 

Dans F exemple suivant : 

<debut> 

<elementl> Premier element </elementl> 

<element2> Second element </element2> 
</debut> 
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• debut est la racine du document, ; 

• elementl et element2 sont les fils de debut ; 

• debut est lepered' elementl et el ement2 ; 

• elementl et element2 sont freres. 

Les elements possedent un contenu delimite par les balises. Ce contenu peut etre : 

• simple s'il s'agit de texte uniquement ; 

• mixte si F element possede a la fois un contenu simple et d'autres elements ; 

• vide : dans ce cas, la balise ouvrante est aussi fermante. Exemple : <saut_de_page/>, qui est equi- 
valent a <saut_de_page></saut_de_page>. 



Remarque 

Tout le contenu d'un element, c'est-a-dire tout ce qui est entre la balise ouvrante et fermante, est analyse par les 
programmes a la recherche d'autres elements. II existe cependant un moyen d'indiquer que le contenu est simple 
et ne necessite pas d'analyse en utilisant une section CDATA. Exemple : 

<texte> <! [CDATA[Ceci est un <contenu> simple]]> </texte> 



Le nommage des types d' elements (c'est-a-dire des balises) doit suivre les regies suivantes : 

• Le nom peut contenir des lettres, des chiffres ou tout autre caractere autorise (voir enumeration 
Unicode dans la specification : http://www.w3c.org/TR/2000/REC-xml-20001006-NT-Name). 

• Le nom ne doit pas commencer par un chiffre ni un caractere de ponctuation. 

• Le nom ne doit pas commencer par xml (quelle que soit la casse). 

• Le nom ne doit pas contenir d'espaces. 

Mis a part ces quelques restrictions, seules les regies de bons sens prevalent pour nommer des 
elements (le nom doit etre clair, precis et concis). 

Un document XML est extensible, ce qui signifie qu'il est possible d'ajouter des elements XML sans 
que cela remette en cause le traitement du document, pourvu que les elements existants demeurent 
inchanges (auquel cas, il ne s'agit plus d'une extension). 

Les elements XML peuvent posseder des attributs. qui permettent d'ajouter des informations 
supplementaires aux elements. Exemple : 

<image type="JPEG"> mon image.jpg </image> 

II n'y a pas de regie pour determiner precisement si une information doit etre traitee en tant qu'attribut 
ou en tant qu'element. Cependant, en general, les attributs sont utilises en tant que metadonnees, pour 
qualifier le contenu des elements. Ce qui est certain, c'est que l'usage des attributs est beaucoup 
moins souple que celui des elements : ils sont difficilement extensibles, leur contenu est simple, etc. 
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XML namespaces 

Les espaces de noms XML ou namespaces sont une extension de la recommandation XML qui a ete 
publiee en Janvier 1999 par le W3C. A l'origine de cette extension, il y a la volonte d'introduire la 
modularite dans les documents XML et de permettre la reutilisation de tout ou partie des documents 
existants. Pour atteindre cet objectif, il est necessaire de doter XML d'un mecanisme permettant 
d'eviter toute ambigulte de nommage (problemes de collisions de noms d'elements ou d'attributs). 



L'attribut xmlns ou xmlns: 

Un espace de noms XML identifie une collection de noms qui sont utilises dans un document XML 
par les elements et les attributs. 

La declaration d'un espace de noms XML est realisee a l'aide de l'attribut reserve xml ns ou d'un attri- 
but specifique precede du prefixe xml ns : . La valeur de cet attribut, une reference d'URI, est le nom de 
l'espace de noms. Par exemple : 

| <soap-env: Envelope xml ns: soap-en v=" http://schemas.xml soap.org/soap/envelope/"> 

est equivalent a : 

<Envelope xml ns=" http://schemas.xml soap.org/soap/envelope/"> 

et declare l'espace de noms http://schemas.xmlsoap.org/soap/envelope/. 

Dans le premier exemple, xml ns : non seulement declare un espace de noms, mais aussi definit un prefixe. 
Tout element ou attribut dont le nom appartient a l'espace de noms doit etre precede de ce prefixe. Par 
exemple : 

<soap-env: Envelope xml ns: soap-en v=" http://schemas.xml soap. org/ soap/envelope/" 
soap-env:encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 

<soap-env:Body> 

</soap-env:Body> 
</soap-env:Envelope> 



Attributs et espaces de noms 

II faut noter, dans I'exemple precedent, qu'encodingStyle est un attribut de l'espace de noms http://schemas 
.xmlsoap.org/soap/envelope/ 



Bien evidemment, il est possible de definir plusieurs espaces de noms dans un meme document ainsi 
qu'un espace de noms par defaut : les regies de portee sont assez logiques et s'appuient sur la hierarchie 
du document. Par exemple : 

<?xml version="1.0"?> 

<!-- definition de l'espace www.eyrolles.com prefixe par pref --> 
<pref :1 ivre xmlns: pref =" http://www.eyro! les. com/ "> 
<!-- l'espace de noms par defaut est HTML --> 
<table xml ns=" http://www.w3.org/TR/REC-html40"> 
<tr> 
<td> 
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<!-- plus d'espace de noms --> 
<titre xmlns="">Ceci est le titre</titre> 
<!-- retour a 1'espace par defaut HTML --> 
</td> 
<td> 
<!-- espace de noms www.eyrolles.com --> 
<pref :sujet>les services Web</pref :sujet> 
<!-- retour a 1'espace par defaut HTML --> 
</td> 
</tr> 
</table> 
</pref :1 ivre> 

Xlink 

XML Linking Language(XLink) version 1.0 est une recommandation du W3C publiee en juin 2001. 
L'objectif de cette specification est de fournir un mecanisme permettant de creer et de decrire, dans 
des documents XML, des liens entre des ressources. Ces liens peuvent etre unidirectionnels ou des 
structures plus complexes. Cette recommandation est complementaire a Xpointer, laquelle fournit un 
mecanisme de definition d'adresses. 

Un peu de vocabulaire 

Un lien (link) est une relation explicite entre des ressources ou des parties de ressources. II est rendu 
explicite par un element liant (linking element), qui est l'element du document XML qui decrit ce 
lien. Une utilisation courante des liens est celle des hyperliens, qui sont des liens destines a etre 
presentes a un utilisateur humain. 

Une ressource est definie comme etant une unite d' information. Elle est identifiee par un URL Lorsqu'un 
lien associe un ensemble de ressources, on dit que ces ressources participent (participate) au lien. 

Un lien simple implique une paire de ressources : la ressource de depart (starting resource) et la 
ressource d'arrivee (ending resource). Un lien etendu implique quant a lui un nombre quelconque de 
ressources. L'information concernant la maniere de traverser une paire de ressources, c'est-a-dire la 
direction et le comportement, est appelee un arc. 

Une ressource locale est un element XML qui participe a un lien en ayant un parent ou en etant lui-meme 
un element liant. Une ressource qui participe a un lien en etant adressee par un URI est considered 
comme une ressource distante (remote) meme si elle se trouve dans le meme document que l'element 
liant. L'element HTML A est un lien simple dont la ressource de depart est une ressource locale et 
dont la ressource d'arrivee est distante. 

Un arc qui a une ressource de depart locale et une ressource d'arrivee distante est hors ligne (outbound), 
c'est-a-dire qu'il quitte l'element liant. L'element HTML A possede done un arc hors ligne. 

Si la ressource d'arrivee d'un arc est locale mais sa ressource de depart distante, alors Fare est en 
ligne (inbound). Si aucune des deux ressources n'est locale, il s'agit d'un arc tiers (third-party). 
Enfin, les documents qui contiennent des collections de liens en ligne et/ou de liens tiers se nomment 
bases de liens (linkbase). 
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Ces derniers concepts sont plus complexes mais neanmoins tres puissants : Xlink permet de creer des 
liens depuis des ressources sans qu'aucune action ne soit necessaire sur cette ressource (distante), 
c'est-a-dire sans qu'il ne soit necessaire de modifier le document contenant cette ressource. C'est le 
sens des liens en ligne. II est meme possible de decrire totalement un lien dans un fichier externe 
(base de liens) sans qu'aucune des ressources participantes ne fasse partie de ce fichier. C'est le sens 
des liens tiers. Ce principe est tres utile lorsque le nombre de ressources est eleve ou lorsque ces 
ressources sont en lecture seule, ou inaccessibles, et de maniere generale lorsqu'il est trop couteux de 
modifier ces ressources et plus interessant de gerer les liens independamment. 

La syntaxe Xlink 

L'usage d'Xlink necessite dans un premier temps la definition de l'espace de noms http://www.w3.org/ 
1999/xlink. En general, le prefixe utilise est xl ink. Par exemple : 

<monlien xmlns:xl ink=" http://www.w3.org/1999/xlink "> ... </monlien> 

Cet espace de noms identifie un ensemble d'attributs qui permet de definir les liens Xlink. Le principal 
attribut est type, qui permet de definir le type de lien. II y a, en effet : 

• des liens simples (ty pe= " s i mpl e " ) qui mettent en relation de facon unidirectionnelle une ressource 
locale et une ressource eloignee, ce sont typiquement les liens HTML A ou IMG ; 

• des liens etendus (type="extended") qui utilisent pleinement les fonctionnalites de Xlink en 
permettant la creation de liens multidirectionnels, de liens en ligne ou tiers. 

Cet attribut permet egalement de qualifier d'autres elements qui servent a la declaration des liens etendus, 
comme : 

• des ressources locales (type=" resource") ; 

• des ressources eloignees (type="locator") ; 

• des regies de traversee (type="arc") ; 

• des litres (type="title"). 

Tableau 6-1. L'usage des attributs Xlink depend du type d'element : obligatoire (O) ou facultatif (F). 
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La definition de ces attributs est la suivante : 

• L'attribut de localisation href permet de definir l'URI de localisation d'une ressource eloignee. 

• Les attributs semantiques role, arcrole et title permettent de definir la signification d'un lien ou 
d'une ressource. Les attributs role et arcrole ont comme valeur des URI alors que l'attribut title 
attend une chaine de caracteres. 

L'exemple suivant declare une ressource eloignee en precisant un role (qui est un URI), un titre, et en 
la nommant MDupond. 

<patron xmlns:xl ink=" http://www.w3.org/1999/xl ink" 
xl ink:type="locator" 

xl ink: href ="http: //wwww. ma societe.com/sal aries/mdupond.xml " 
xl ink: role="http: //www. ma societe.com/di recti on" 
xlink:title="Michel Dupond" 
xl ink:label="MDupond"/> 

• L'attribut show indique la maniere de presenter la ressource d'arrivee du lien. II peut prendre 
comme valeur "new" (nouvelle presentation), "repl ace" (dans la meme presentation), "embed" (a la 
place), "other" (determine ailleurs) ou "none" (indetermine). 

• L'attribut actuate indique quand la traversee vers la ressource d'arrivee doit etre executee. II peut 
prendre comme valeur "onLoad" (des le chargement de la ressource de depart), "onRequest" (a la 
demande), "other" (determine ailleurs) ou "none" (indetermine). 

Dans l'exemple qui suit, ce lien simple est parcouru des le chargement de la page et le resultat est 
affiche dans une nouvelle fenetre : 

<eyrol les: logo xmlns:eyrolles=" http://www.eyro! les.com" 
xmlns:xl ink=" http://www.w3.org/1999/xl ink" 
xl ink:type=" simple" 

xl i nk: href =" http://www.eyro! les.com/images/eyro! les_4_petit.gif" 
xl ink:show="new" 
xl ink:actuate="onl_oad"/> 

• Les attributs 1 abel , from et to permettent d'identifier les nceuds du document XML. Si une valeur 
est affectee a from ou to, elle doit correspondre a la valeur affectee a l'attribut 1 abel d'un element 
locator ou resource. 

Dans l'exemple suivant, ce lien etendu definit deux ressources eloignees et un arc entre ces deux 
ressources : 

<societe xmlns:xl ink="http:/ /www. w3.org/1999/xl ink" 
xl ink:type="extended" 
xl ink:title="Ma societe"> 
<auteur xmlns:xl ink=" http://www.w3.org/1999/xl ink" 

xlink:type="locator" 

xl ink: href =" http://www.eyro! les.com/auteurs/lmaesano.xml " 

xl ink:role=" http://www.ey roll es.com/servicesweb/guru" 

xl ink:title="Libero Maesano" 

xl ink:label="LMaesano"/> 
<auteur xmlns:xl ink=" http://www.w3.org/1999/xl ink" 

xl ink:type="locator" 
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xl i nk: href =" http://www.eyro! les.com/auteurs/xlegalles.xml " 
xl ink:role=" http://www.eyro! les.com/servicesweb/wizard" 
xl ink:title="Xavier Le Galles" 
xlink:label="XLegalles"/> 
<edition xmlns:xl i nk="http : //www. w3.org/1999/xl ink" 
xl ink:type="arc" 
xl ink:f rom="X Legal les" 
xl ink:to="LMaesano" 

xl i nk: a rcrole=" http://www.ey rolles.com/co-auteur" 
xl ink:title="est co-auteur avec"/> 
</societe> 



Utilisation de certains attributs 

La specification ne definit pas de fagon formelle la maniere dont les attributs role, arcrole, title, show et 
actuate doivent etre utilises. 



XML Base 



XML Base 1.0 est une recommandation du W3C publiee en juin 2001. Son objectif est de definir 
dans un document XML un chemin de base permettant d' interpreter de facon relative tous les URI 
contenus dans le document et implemented en XLink. L objectif de cette specification est equivalent 
a celui d'HTML Base. 



L'attribut xmhbase 

Le principe de fonctionnement de XML Base est simple. II consiste a ajouter un attribut xml :base a 
n'importe quel nceud d'un document XML. La valeur de cet attribut est un URI de base utilise par 
tous les liens Xlink exprimes dans le nceud. Par - exemple : 

<? XML version="1.0" encoding="IS0-8859-l" ?> 
<carnet_adresses xml :base="http://www. monSite.com/commun/" 
xmlns:xl ink=" http://www.w3.org/1999/xl ink"> 
<!-- http://www.monSite.com/commun/identite.xml --> 
<titre>Mon carnet 

< 1 ink xl ink:type="simple" xl ink: href ="identite. xml ">personnel </l ink> 
</titre> 

<liste xml :base="/adresses/"> 
<adresse id="l"> 
<nom> 

<!-- http://www.monSite.com/adresses/dupont.xml --> 
< 1 ink xl ink:type=" simple" xl ink: href ="dupont. xml ">Dupont</link> 
</nom> 

<prenom>Bernard</prenom> 
<cp>75014</cp> 
</adresse> 
</liste> 
</carnet_adresses> 
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XPath 



XML Path Language 1.0 (XPath) est une recommandation du W3C publiee en novembre 1999. 
L'objectif de cette specification est de fournir un mecanisme permettant d'adresser des parties de 
document XML, mecanisme utilise a la fois par XSLT et XPointer. Le nom de cette technologie vient du 
fait qu'elle utilise des chemins (path) equivalents aux URL pour naviguer dans la structure hierarchique 
des documents XML. 

Par exemple, pour le document XML suivant : 

<? XML version-"].. 0" encoding="IS0-8859-l" ?> 
<carnet_adresses> 
<adresse id="l"> 

<nom>Dupont</nom> 

<prenom>Bernard</prenom> 

<cp>75014</cp> 
</adresse> 
<adresse id="2"> 

<nom>Durand</nom> 

<prenom>Paul</prenom> 

<cp>06220</cp> 
</adresse> 
<adresse i d = " 3 " > 

<nom>Vincent</nom> 

<prenom>Pierre</prenom> 

<cp>21017</cp> 
</adresse> 
</carnet_adresses> 

1' expression XPath suivante selectionne tous les noms du carnet d'adresses : 

/carnet_adresses/adresse/nom 

Les expressions XPath 

Les documents XML peuvent etre representes comme des arbres de nceuds appartenant a un des sept 
types suivants : 

• le type racine, qui est utilise pour la racine du document ; 

• le type element, qui est utilise pour les elements d'un document. Le nom d'un element peut etre 
exprime en precisant un espace de noms ; 

• le type texte, qui est utilise pour les valeurs d' elements donnees caracteres (y compris < ! [CDATA[...] ]>) ; 

• le type attribut, qui est utilise pour les attributs d'un element ; 

• le type espace de noms, qui est utilise pour les attributs ou elements affectes par la declaration d'un 
espace de noms (attribut xml ns ou prefixe xml ns :) ; 

• le type instruction, qui est utilise pour les instructions XML <? ... ?> (mis a part F instruction de 
declaration XML en en-tete qui ne possede pas de noeud) ; 

• le type commentaire, qui est utilise pour les commentaires <!- - ... -->. 
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Une expression XPath permet d'obtenir un ensemble de nceuds, de n'importe quel type, du document 
XML. Cette expression se traduit sous la forme d'un chemin qui peut etre : 

• absolu s'il commence par un « / », le chemin identifie alors de maniere constante un ensemble de 
nceuds a partir de la racine du document ; 

• relatif lorsqu'il ne commence pas par un « / », le resultat depend alors de Fendroit oil F expression 
est appliquee lors de la navigation dans l'arbre. 

Syntaxe longue 

Le chemin est constitue de marches separees par des « / » (barres obliques). Une marche est constitute : 

• d'un axe, qui definit la relation entre les nceuds identifies par la marche et le contexte en cours ; 

• d'un test de nceud, qui s' applique aux types et aux noms des nceuds selectionnes ; 

• d'un ou plusieurs predicats, qui permettent d'affiner la selection des nceuds. 
La syntaxe d'une marche est : axe: :noeud[pred1cat]. 

L'exemple suivant selectionne toutes les adresses dont Fid est 3 : 
/child: :carnet_adresses /child: :adresse[ attribute: :id="3"] 

Tableau 6-2. Les valeurs possibles d'un axe. 

Axe Description 

Ancestor Tous les ancetres (parents, grands-parents, etc., y compris la racine) du nceud courant. 

ancestor-or-sel f Idem plus le nceud courant. 

Attn bute Tous les attributs du noeud courant. 

Chi 1 d Tous les enfants du nceud courant. 

Descendant Tous les descendants (enfants, petits-enfants, etc.) du nceud courant (sans les noeuds de type attribut 

ou espace de noms). 

descendant-or-sel f Idem plus le nceud courant. 

Fol 1 owi ng Tous les nceuds qui suivent le nceud courant dans I'ordre du document, sauf les noeuds de type attribut 

ou espace de noms et en dehors des descendants directs. 

fol 1 owing-si bl i ng Tous les noeuds qui suivent le nceud courant dans I'ordre du document et possedent le meme pere 
(pour un type attribut ou espace de noms, le resultat est vide). 

Namespace L'espace de noms du nceud courant. 

Parent Le parent du nceud courant. 



Precedi ng Tous les nceuds qui precedent le nceud courant dans I'ordre du document, sauf les nceuds de type 

attribut ou espace de noms et en dehors des ancetres directs. 

preceding-sibling Tous les nceuds qui precedent le nceud courant dans I'ordre du document et possedent le meme 
pere (pour un type attribut ou espace de noms, le resultat est vide). 

Self Le nceud courant uniquement. 
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Tableau 6-3. Les possibilites de test de noeuds. 



Type de test 


Valeur 


Description 


Noms 
des noeuds 


Le nom du noeud exprime avec ou sans espace 
de noms. 


Retourne les noeuds dont le nom est celui specifie (et 
correspondant au type). 


* 


Retourne tous les noeuds (correspondant au type). 


Types 
des noeuds 


Commentt ) 


Retourne les noeuds de type commentaire. 


TextO 


Retourne les noeuds de type texte. 


processing -instruction! ) 


Retourne les nceuds de type instruction (dont le nom 
peut etre specifie). 


NodeO 


Retourne tous les noeuds. 



Enfin, les predicats permettent de filtrer l'ensemble des noeuds selectionnes d'apres des expressions. 
Ces expressions peuvent etre combinees entre elles a l'aide de Foperateur d'union (I). 

Tableau 6-4. Construction des expressions de predicat. 



Type d'expression 


Valeur 


Description 


Appels de fonction 


Nom de la fonction. 


(Voir tableau 6-5). 


Ensemble de noeuds 


Chemin XPath. 




Expressions booleennes 


= ou! = 


Egal ou different. 


<, <=, >ou>= 


Inferieur, inferieur ou egal, superieur ou superieur ou egal. 


or ou and 


Ou ou et logique. 


Expressions numeriques 


+ OU - 


Addition ou soustraction. 


*, divoumod 


Multiplier, diviser ou reste de la division. 


Expressions regulieres 


Expression reguliere. 


Expression reguliere appliquee a un nom ou a type de noeud. 



Tableau 6-5. Les fonctions predefines applicables aux ensembles de noeuds. 



Fonction 

countt...) 

id(_) 

lastO 

local -name(_) 

name(...) 

namespace-uri (...) 

position! ) 



Description 

Retourne le nombre d'elements de l'ensemble passe en argument. 

Selectionne les elements d'apres leur identifiant unique. 

Retourne un nombre egal a la taille du contexte defini par I'expression. 

Retourne le nom local (sans espace de noms) du premier noeud de l'ensemble passe en argument. 
Si I'argument est absent, l'ensemble est determine par le contexte. 

Retourne le nom (y compris I'espace de noms) du premier noeud de l'ensemble passe en argument. 
Si I'argument est absent, l'ensemble est determine par le contexte. 

Retourne I'URI de I'espace de noms du premier nceud de l'ensemble passe en argument. Si I'argument 
est absent, l'ensemble est determine par le contexte. 

Retourne un nombre egal a la position du contexte. 
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Tableau 6-6. Les fonctions de chames de caracteres predefinies. 

Fonction Description 

stringt...) Retourne la conversion d'un objet en chaine de caracteres. 

concatt...) Retourne la concatenation des arguments. 

starts-with(...) Renvoie vrai si la chaine en premier argument commence par la chaine passee en second 

argument. 

Renvoie vrai si la chaine en premier argument contient la chaine passee en second argument. 

Retourne une sous-chaine de caracteres du premier argument qui precede la premiere occurrence 
de la chaine passee en second argument. 

Retourne une sous-chaine de caracteres du premier argument qui suit la premiere occurrence de 
la chaine passee en second argument. 

Retourne une sous-chaine de caracteres du premier argument qui commence a la position 
determinee par le deuxieme argument et qui est d'une longueur egale au troisieme argument. 

Retourne la longueur de la chaine de caracteres passee en argument. Si I'argument est absent, 
la chaine correspond au nom du noeud courant. 

Retourne la chaine de caracteres passee en argument apres avoir supprime les espaces de debut 
et de fin et apres avoir remplace les espaces consecutifs par un espace unique. Si I'argument est 
absent, la chaine correspond au nom du noeud courant. 

Retourne la chaine de caracteres passee en premier argument apres avoir remplace toutes 
les occurrences de la chaine passee en deuxieme argument par la chaine passee en troisieme 
argument. 



containst...) 
substring-beforeC.) 

substring-aftert...) 

substring^..) 

string-length(_) 

normal ize-space(...) 

transl ate(...) 



Tableau 6-7. Les fonctions booleennes predefinies. 



Fonction 


Description 


boolean!...) 


Convertit I'objet passe en argument en booleen vrai si cet objet est : 

- un nombre different de ou NaN ; 

- un ensemble de nceuds non vide ; 

- une chaine de caracteres de longueur non nulle. 

Pour les autres types d'objets, le resultat depend du type d'objet. 


not(...) 


Retourne la negation booleenne de I'argument. 


true( ) 


Retourne vrai. 


falseO 


Retourne faux. 


lang(...) 


Retourne vrai si la langue du noeud courant est la meme (ou une sous langue) que celle passee en 
argument. La langue est determinee par I'attribut xml : 1 ang. 
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Tableau 6-8. Les fonctions numeriques predefines. 

Fonction Description 

number (_.) Retourne v ra 1 si la langue du nceud courant est la meme (ou une sous-langue) que celle passee en argument. 

La langue est determinee par I'attribut xml : 1 ang. 

number (~) Convertit I'objet passe en argument en nombre : 

- valeur mathematique d'une chaine de caracteres ; 

- 1 pour vrai et pour faux ; 

- un ensemble de noeuds est d'abord converti en chaine de caracteres par la fonction stri ng( ) puis en 
numerique. 

Pour les autres types d'objets, le resultat depend du type d'objet. 

Si I'argument est absent, la conversion s'applique a I'ensemble de noeuds determine par le contexte. 

sum(...) Retourne la somme de tous les noeuds de I'ensemble passe en argument (valeur des nceuds convertie en 

numerique). 

floor(._) Retourne le plus grand nombre entier qui nesoit pas plus grand que I'argument. 

ceilingC.) Retourne le plus petit nombre entier qui ne soit pas plus petit que I'argument. 

round(._) Retourne le nombre entier qui est le plus prochede la valeur passee en argument. 



Syntaxe abregee 

Tableau 6-9. Les expressions XPath peuvent etre abregees. 



Abrevlatlon 


Syntaxe longue 




Rien 


child:: 




@ 


attribute: : 




self : :node( ) 


parent: :node( ) 


// 


/descendant-or-self : 


:node( )/ 



Voici quelques exemples 
Exemple 



//adresse 

/carnet_adresses/adresse[2] 

adresse[@id="3"] 



Description 

Selectionne tous les elements de type adresse. 
Selectionne la seconde adresse. 
Selectionne le nceud adresse dont I' 1 d est 3. 



XML Schema 

XML Schema 1.0 est une recommandation du W3C qui a ete publiee en mai 2001. L'objectif de cette 
specification est de fournir un mecanisme de description et de validation des documents XML, equi- 
valent a la DTD mais plus expressif, extensible et surtout utilisant lui-meme une syntaxe XML et les 
espaces de noms. 
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Abreviation et prefixe XSD 

On parle aussi d'XML Schema Definition ou XSD. Cette abreviation est souvent utilisee comme prefixe du nom 
d'espace de noms XML Schema et comme extension des fichiers de schemas. 



Globalement, XML Schema permet de creer un modele de document (un schema) qui definit : 

• les elements et les attributs qui peuvent apparaitre dans le document ; 

• l'ordre et 1' occurrence des elements fils ; 

• si un element est vide ou s'il a un contenu ; 

• les types de donnees des elements et des attributs ; 

• les valeurs par defaut des elements et des attributs. 

Description d'un schema XML 

Un schema XML est d'abord un document XML 1.0 bien forme et valide au regard de ses specifications, 
c'est-a-dire soit en utilisant le schema des schemas, soit la DTD des schemas (respectivement dans 
les annexes A et G de la recommandation du W3C). 

Le vocabulaire (noms d' attributs et d' elements) est defini dans deux espaces de noms : 

• http://www.w3.org/2001/XMLSchema : cet espace de noms definit la plus grande partie du vocabulaire 
d'XML Schema. Pour simplifier la suite de ce chapitre, on utilisera systematiquement le prefixe 
xsd : pour referencer cet espace de noms. 

• http://www.w3.org/2001/XMLSchema-instance : cet espace de noms definit des attributs qui peuvent etre 
utilises dans tout document XML (type, null schema Location et noNamespaceSchema Location). Pour 
simplifier la suite de ce chapitre, on utilisera systematiquement le prefixe xsi : pour referencer cet 
espace de noms. 

Le schema est un modele qui peut etre applique a des instances de documents XML. En general, un 
modele est fait pour etre reutilise et il est preferable de le confier a un document a part plutot que de 
le voir defini dans le corps du document XML auquel il s' applique. Le lien entre le document XML 
et le schema est realise a partir des attributs xsi :schemaLocation ou xsi :noNamespaceSchemaLocation 
qui permettent de referencer PURL du schema. Ce lien implique qu'un travail de validation devra 
etre effectue sur P instance de document par un programme adequat (voir la section « Les analyseurs 
syntaxiques XML »). 

Un schema XML peut etre reparti dans plusieurs documents. Deux mecanismes d'inclusion sont fournis : 

• <xsd:include>, qui permet d'inclure un schema et d'utiliser telles quelles les definitions et les 
declarations de ce schema ; 

• <xsd : redef i ne>, qui permet non seulement d'inclure un schema mais aussi de redefinir les types de 
ce schema par restriction ou extension. 

Dans les deux cas, l'attribut schemaLocation permet de specifier PURL du document a inclure. De 
plus, ce schema externe doit posseder le meme espace de noms cible que le schema dans lequel il est 
inclus. 
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Ce mecanisme d' inclusion est tres important puisqu'il permet la modularite : au fur et a mesure 
qu'XML Schema prend de Fessor, des bibliotheques de schemas se creent et peuvent etre reutilisees 
par les developpeurs et les concepteurs. 

En tant que document XML, un schema possede une racine qui est obligatoirement l'element <schema>. 
Par exemple : 

<xsd: schema 

xmlns:xsd=" http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.eyrol 1 es.com" 

</xsd:schema> 
Cet element possede plusieurs attributs specifiques : 

• targetNamespace, qui permet de specifier Fespace de noms cible des elements et des attributs definis 
par ce schema ; 

• attributeFormDefault="qualified" ou "unqualified", qui permet de preciser si les noms des attributs 
doivent etre qualifies ou pas a Faide du nom d'espace de noms cible ; 

• el ementFormDef aul t="qual 1 f i ed" ou "unqual i f i ed", qui permet de preciser si les noms des elements 
doivent etre qualifies ou pas a Faide du nom d'espace de noms cible, etc. 

Un schema XML est constitue d'un ensemble de composants : 

• de definition, qui servent a creer de nouveaux types, simples ou complexes, par derivation de types 
existants ; 

• de declaration, qui permettent de specifier les noms et les types de contenus des elements et des 
attributs qui pourront etre utilises dans les instances de document XML. 

Les composants de declaration 

Les composants de declaration permettent de definir : 

• des elements grace a l'element <xsd : el ement> ; 

• des attributs grace a l'element <xsd: attribute) ; 

• des notations grace a l'element <xsd : notati on>. 

Les attributs sont identifies par leur nom (attribut name) et ne peuvent etre que de types simples. La 
declaration comporte d'autres informations utiles : 

• def aul t indique une valeur par defaut ; 

• fixed indique une valeur fixe et par defaut ; 

• use indique si Fattribut est optionnel ("opti onal "), interdit ("prohi bi ted") ou obligatoire ("requi red"). 
Par exemple : 

<xsd:attribute name="pays" type="xsd:NMTOKEN" fixed="FR"/> 



Technologies des services Web 

Deuxieme Partie 

Les elements sont identifies par leur nom (attribut name) et peuvent etre de n'importe quel type, simple 
ou complexe. La declaration comporte d'autres informations utiles : 

• defaul t indique une valeur par defaut ; 

• f i xed indique une valeur fixe et par defaut ; 

• maxOccurs precise le nombre d'occurrences maximal de l'element ; 

• minOccurs precise le nombre d'occurrences minimal de l'element (0 signifie optionnel, sinon 
obligatoire). 

Par exemple : 

<xsd: element name="codePostal " minOccur="l"> 
<xsd:simpleType> 

<xsd: restriction base="xsd:string"> 

<xsd:pattern val ue="\d{5}"/> 
</xsd:restriction> 
</xsd:simpl eType> 
</xsd:element> 

Un attribut particulier, substi tuti onGroup, permet d'utiliser un mecanisme interessant de substitution : 
le principe est de definir un groupe d' elements pouvant se substituer a un element global appele 
element de tete. La contrainte est que les groupes de substitution doivent etre du meme type ou d'un 
type derive de l'element de tete. 

Dans l'exemple suivant, l'element codePostalUS peut etre substitue a l'element de tete codePostal 
partout ou celui-ci est utilise : 



<xsd:element name="codePostal " type="xsd:string"/> 



<xsd:element name="codePostalUS" type="xsd:string" substitutionGroup="codePostal "> 

Si les declarations sont effectuees directement a l'interieur de <xsd:schema>, elles sont globales, 
sinon (si elles sont declarees a l'interieur de types complexes), elles sont locales. Ce qui est interessant 
avec les declarations globales, c'est qu' elles peuvent etre reutilisees par d'autres declarations a l'aide 
de F attribut ref. Par exemple : 

<xsd:schema 

xmlns:xsd=" http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.eyrol les.com" 
<xsd:element name="codePostal "> 
<xsd:simpleType> 

<xsd: restriction base="xsd:string"> 

<xsd:pattern val ue="\d{5}"/> 
</xsd:restriction> 
</xsd:simpl eType> 
</xsd:element> 

<xsd:element name="adresse"> 
<xsd:element name="nom" type="xsd:string"> 
<xsd: element name="prenom" type="xsd:string"> 
<xsd:element name="adresse" type="xsd:string"> 
<xsd:element name="CP" ref="codePostal " min0ccur="l"> 
</xsd:element> 
</xsd:schema> 
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Les composants de definition 

Les composants de definition permettent de definir des types qui peuvent etre reutilises dans d'autres 
composants. Les definitions de types sont hierarchisees dans la mesure oil toute definition de type est 
une extension ou une restriction d'une autre definition de type. La definition du type ur-type, dont le 
nom est anyType, est la racine de cette hierarchie. 

XML Schema permet de definir deux categories de types, a savoir simples et complexes. 

Definition de types simples 

Les types simples s'appliquent aux valeurs d'attributs et au contenu textuel d' elements (qui n'ont pas 
d'elements enfant). Un type simple est obligatoirement une restriction d'un type de base simple. XML 
Schema fournit un certain nombre de types predefinis qui sont utilises pour creer les types utilisateur 
(voir figure 6-1). 



types complexes 



anyType 





anySimpleType 






1 








1 








duration 


dateTime 


time 


date 


gYearMonth 


gYear 


gMonthDay 


gDay 


gMonth 


























1 


string 


boolean 


base64Binary 


hexBinary 


float 


decimal 


double 


anyURI 


QName 


NOTATION 



normalizedString 



integer 



token 



nonPositivelnteger 



long 



nonNegativelnteger 





I I I 




language 


name 


NMTOKEN 








NCName 


NMTOKENS 






l 


I 




ID 


IDREF 


ENTITY 












IDREFS 


ENTITIES 





negativelnteger 



int 



unsignedLong 



positivelnteger 



short 



unsignedlnt 



byte 



unsignedShort 



unsignedByte 



Legende 



type ur 

type primitif pre-defini 
type derive pre-defini 
type complexe 



derivation par restriction 

derivation par liste 

derivation par extension ou restriction 



Figure 6-1 

La hierarchie des definitions de types d'XML Schema. 
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Un type simple est defini a partir de F element <xsd : simpl eType> et identifie par son nom (attiibut name). 
La definition d'un type simple doit contenir des elements fils qui peuvent etre de trois types : 

• des elements de contraintes <xsd : restri cti on> appdees facettes ; 

• des elements de liste de valeurs <xsd : 1 i st> ; 

• des elements d'union de types simples <xsd:union>. 

Les facettes peuvent etre appliquees directement dans la definition du type simple ou indirectement 
aux elements de liste et d'union. 

Tableau 6-10. Les restrictions ou facettes. 

Element Description 

Enumeration Definit une liste de valeurs autorisees. 

fractionDigits Definit le nombrede decimales autorisees (superieur ou egal a zero). 

Length Definit le nombre exact de caracteres ou d'entrees dans une liste (super ieur ou egal a zero). 

MaxExcl us i ve Definit la valeur numerique maximale (le contenu doit etre inferieur). 

Maxlncl usi ve Definit la valeur numerique maximale (le contenu doit etre inferieur ou egal). 

MaxLength Definit le nombre maximal de caracteres ou d'entrees dans une liste (super ieur ou egal a zero). 

MinExclusive Definit la valeur numerique minimale (le contenu doit etre superieur). 

mi nlncl usi ve Definit la valeur numerique minimale (le contenu doit etre superieur ou egal). 

Mi n Length Definit le nombre minimal de caracteres ou d'entrees dans une liste (superieur ou egal a zero). 

Pattern Definit une expression reguliere qui doit etre verifiee de maniere exacte. Prend en charge Unicode 

et est applicable atous les types predefinis sauf binary, IDREFS, ENTITIES et NMTOKENS. 

total Digits Definit le nombre exact de chiffres. 

WhiteSpace Definit comment les espaces doivent etre interprets (y compris LF, Tab, espaceetCR). 



Par exemple : 

<xsd:schema xmlns:xsd=" http://www.w3.org/2001/XMLSchema" 
targetNamespace=" http://www.eyro! les. com" > 
<xsd:simpleType name="typeCodePostal FR"> 
<xsd: restriction base="xsd:string"> 

<xsd:pattern value="\d{5}"/> 
</xsd: restriction> 
</xsd:simpleType> 

<xsd:simpl eType name="typeTypeAdresse"> 
<xsd: restriction base="xsd:string"> 
<xsd: enumeration val ue=" Personnel "/> 
<xsd: enumeration val ue="Professionnel "/> 
</xsd: restriction) 
</xsd:simpleType> 

<xsd: simpl eType name="typeTelephone"> 
<xsd: restriction base="xsd:string"> 
<xsd:length value="ll"/> 
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<xsd: pattern val ue="\d{2}-\d{2}-\d{2}-\d{2} "/> 
</xsd: restriction 
</xsd:simpleType> 
</xsd:schema> 

Les types liste de valeurs <xsd : 1 i st> permettent de completer les types predeflnis NMTOKENS, IDREFS 
et ENTITIES. Ces listes ne peuvent etre que des derivations de types atomiques existants et le separateur 
des elements de la liste est l'espace. 

L'exemple suivant definit le type "typePhrase" comme etant une liste de chaines de caracteres (un 
enchainement de mots separes par des espaces) : 

<xsd:simpl eType name="typePhrase"> 

<xsd:l ist itemType="xsd:string"/> 

</xsd:simpl eType> 
<xsd:el ement name="phrase" type="typePhrase"/> 

Les types union <xsd : uni on> permettent de creer des types composes d'une ou plusieurs instances de 
types atomiques ou listes. Par exemple : 

<xsd:schema xmlns:xsd=" http://www.w3.org/2001/XMLSchema" 
ta r get Namespace=" http://www.eyro! les .com"> 
<xsd: si mpl eType name="numDeptCA"> 
<xsd:restriction base=xsd:string > 
<xsd: enumeration va1ue="04"/> 
<xsd:enumeration value="05"/> 
<xsd:enumeration val ue="06"/> 
<xsd:enumeration value="13"/> 
<xsd:enumeration value="83"/> 
<xsd:enumeration value="84"/> 
</xsd:restriction> 
</xsd:simpleType> 
<xsd: si mpl eType name="strDeptCA"> 
<xsd:restriction base=xsd:string > 

<xsd:enumeration val ue="Alpes de Haute Provence"/> 
<xsd:enumeration val ue="Hautes Alpes"/> 
<xsd:enumeration value="Alpes Maritimes"/> 
<xsd:enumeration val ue="Bouches du Rhone"/> 
<xsd:enumeration val ue="Var"/> 
<xsd: enumeration val ue="Vaucl use"/> 
</xsd:restriction> 
</xsd:simpleType> 
<xsd:simpleType name="typeDeptCoteAzur" final="#all "> 

<xsd:union memberTypes="numDeptCA strDeptCA"> 
</xsd:simpleType> 
</xsd:schema> 

Lors de la definition d'un type simple, il est possible d'interdire ou de contraindre la derivation du 
type en question grace a Fattribut final. Dans l'exemple precedent, toute derivation du type "type- 
DeptCoteAzur" est interdite. 
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Definition de types complexes 

Un type complexe peut etre utilise uniquement pour typer le contenu d'elements et ne s'applique pas 
aux attributs. II contient a la fois des definitions de types et des declarations d'elements et d'attributs 
arm de permettre la definition de structures complexes. 

Un type complexe est defini a partir de l'element <xsd : compl exType> et identifie par son nom (attribut 
name). Lors de la definition d'un type complexe, il est possible d'interdire ou de contraindre la deriva- 
tion du type en question grace a Fattribut f 1 nal . 

II y a quatre types d'elements complexes : 

• les elements vides ; 

• les elements qui contiennent uniquement d'autres elements ; 

• les elements qui ne contiennent que du contenu litteral (aucun element) ; 

• les elements mixtes qui ont a la fois des elements et un contenu litteral. 

Chacun de ces quatre types d'elements complexes peut en outre contenir des declarations d'attributs. 

Pour definir un type complexe qui ne contient que du contenu litteral sans elements, on utilise 
l'element <xsd:simpleContent>. II est obligatoire d'indiquer alors le type de derivation utilise, soit 
grace a l'element <xsd: extension^ soit grace a l'element <xsd:restriction>. Parexemple : 

<xsd: compl exType name="typeChaineVal ide"> 
<xsd:simpleContent> 

<xsd: restriction base="xsd:string"> 

<xsd:annotation>une chaine ne doit pas contenir 2 "-"</xsd:annotation> 
<xsd: pattern value="( [ A - ]-?)*"/> 
</xsd: restriction> 
</xsd:simpleContent> 
</xsd:compl exType> 



Usage des annotations 

On notera dans cet exemple I'usage de l'element <xsd:annotation> qui, comme son nom I'indique, permet 
d'ajouter des annotations dans les schemas, destinees a la fois aux programmeurs et aux utilisateurs. 



Pour definir un type complexe qui ne contient que des elements, on utilise l'element <xsd: compl ex- 
ContentX II est obligatoire d'indiquer alors le type de derivation utilise, soit grace a l'element 
<xsd:extension>, soit grace a l'element <xsd:restriction>. Si aucun element n' est defini pourun tel 
type, il s'agit alors d'un element vide de tout contenu. 

Les types complexes ayant un contenu mixte sont definis en speciflant 1' attribut mixed="true" 
(element <xsd: compl exType>). 

Pour les types complexes contenant des elements (type mixte ou elements uniquement), il est possible 
de definir des modeles de contenu a partir d'une combinaison des trois constructions suivantes : 

• <xsd : all > : definit un ensemble non ordonne d'elements fils qui doivent apparaitre une et une seule 
fois ; 
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• <xsd : choi ce> : definit un ensemble d'elements parmi lesquels un seul devra apparaitre ; 

• <xsd:sequence> : definit un ensemble ordonne d'elements. 

Ces trois modeles de contenu ne peuvent pas etre nommes et ne peuvent done pas etre declares de 
maniere globale. Pour contourner cette limitation, il faut utiliser une definition de groupe grace a 
l'element <xsd group>. Parexemple : 

<xsd:schema xmlns:xsd=" http://www.w3.org/2001/XMLSchenia" 
ta r get Namespace=" http://www.eyrolles.com"> 
<!-- definitions de types --> 

<!-- declarations globales --> 
<xsd:element name="nom" type="xsd:string"/> 
<xsd:element name="prenom" type="xsd:string"/> 
<xsd: element name="adresse" type="xsd:string"/> 
<xsd:element name="telephone" type="typeTelephone"/> 
<xsd:element name="CP" type=" typeCodePostal FR"/> 
<!-- definition d'un groupe global --> 
<xsd: group name="groupAdresse"> 
<xsd:sequence> 

<xsd:element ref="nom" minOccurs="l" maxOccurs="l"/> 
<xsd:element ref="prenom" minOccurs="l" maxOccurs="l"/> 
<xsd:element ref="adresse" minOccurs="l" max0ccurs="2"/> 
<xsd:element ref="tel ephone" minOccurs="l" maxOccurs="l"/> 
<xsd:element ref="CP" minOccurs="l" maxOccurs="l"/> 
</xsd:sequence> 
</xsd:group> 

<!-- definition d'un element complexe de type element-only --> 
<xsd:element name="adresse"> 
<xsd : compl exContent> 

<xsd: group ref="groupAdresse"/> 
</xsd: compl exCon ten t> 
</xsd:element> 
</xsd:schema> 

De la meme maniere, il est possible de definir des groupes d'attributs nommes grace a l'element 
<xsd:attributeGroup> qui pourront etre reutilises dans des definitions de types complexes. On 
appelle les elements et les groupes utilises dans la definition d'un element complexe, des particules. 
Par exemple : 

<xsd:schema xmlns:xsd=" http://www.w3.org/2001/XMLSchema" 
target Namespace=" http://www.eyro! les .com"> 
<!-- definitions de types --> 

<!-- declarations globales --> 

<!-- definition d'un groupe d'elements global --> 

<!-- definition d'un groupe d'attribut global --> 
<xsd:attributeGroup name="attributAdresse"> 
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<xsd: attribute ref="xml :1 ang" use="requi red"/> 

<xsd:attribute type="typeTypeAdresse" use="requi red"/> 
</xsd:attributeGroup> 

<!-- definition d'un element complexe de type element-only --> 
<xsd:element name="adresse"> 

<xsd : compl exContent> 

<xsd:group ref="groupAdresse"/> 

</xsd : compl exContent> 

<xsd:attributeGroup ref="attributAdresse"/> 
</xsd:element> 
</xsd:schema> 

Pour permettre une extensibilite maximale des schemas XML, deux elements sont introduits : 

• <xsd : any>, qui permet d'etendre le modele en autorisant des elements non definis dans le schema ; 

• <xsd : anyAttri bute>, qui permet d'etendre le modele en autorisant des attributs non definis dans le 
schema. 



Les definitions complementaires 

XML Schema permet de definir une contrainte d'unicite pour des valeurs d' attributs ou d'elements. 
Ce mecanisme s'appuie sur l'element <xsd : uni que> et les elements his suivants : 

• <xsd : sel ector>, dont l'attribut xpath permet de specifier un chemin XPath definissant le perimetre 
auquel s' applique la contrainte ; 

• <xsd : f i el d>, dont l'attribut xpath permet de specifier un chemin XPath definissant les elements ou 
les attributs dont la valeur doit etre unique au sein du perimetre precise par <xsd : sel ector>. 

Reprenons l'exemple XML suivant : 

<? XML version="1.0" encoding="IS0-8859-l" ?> 
<carnet_adresses> 
<adresse id="l"> 

<nom>Dupont</nom> 

<prenom>Bernard</prenom> 

<cp>75014</cp> 
</adresse> 
<adresse id="2"> 

<nom>Durand</nom> 

<prenom>Paul </prenom> 

<cp>06220</cp> 
</adresse> 
<adresse id="3"> 

<nom>Vincent</nom> 

<prenom>Pierre</prenom> 

<cp>21017</cp> 
</adresse> 
</carnet_adresses> 
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Si nous voulons indiquer l'unicite de l'element nom, le schema doit etre defini ainsi : 

<xsd:unique name="charName"> 

<xsd:selector xpath="adresse"/> 

<xsd:field xpath="nom"/> 
</xsd:unique> 

XML Schema fournit egalement un mecanisme de definition de cle : 

• <xsd : key> qui en plus du caractere d'unicite, garantit que les valeurs sont obligatoirement renseignees ; 

• <xsd : sel ector>, dont l'attribut xpath permet de specifier un chemin XPath definissant le perimetre 
auquel s' applique la contrainte de cle ; 

• <xsd:field>, dont l'attribut xpath permet de specifier un chemin XPath definissant l'element ou 
l'attribut dont la valeur doit etre unique et obligatoire (cle) au sein du perimetre precise par 
<xsd:selector>. 

Ce mecanisme est accompagne d'une notion de reference de cle : 

• <xsd : key ref > dont l'attribut refer permet de specifier la cle de reference ; 

• <xsd : sel ector>, dont l'attribut xpath permet de specifier un chemin XPath definissant le perimetre 
auquel s' applique la contrainte de cle de reference ; 

• <xsd:field>, dont l'attribut xpath permet de specifier un chemin XPath definissant l'element ou 
l'attribut dont la valeur doit etre une reference de cle au sein du perimetre precise par <xsd : sel ectorX 

En reprenant l'exemple precedent, la definition de la cle id de l'element adresse est la suivante : 

<xsd:unique name="charName"> 

<xsd:selector xpath="adresse"/> 

<xsd:field xpath="id"/> 
</xsd:unique> 

L interface DOM 

L'objectif du Document Object Model (DOM) est de fournir une interface de programmation (API) 
standardisee, independante de la plate-forme et des langages, pour acceder et mettre a jour le contenu 
et la structure de documents HTML et XML. Une telle interface permet par exemple a un programme 
de script de manipuler une page HTML independamment du navigateur. 

II existe plusieurs recommandations : 

• DOM Level 1 : recommandation d'octobre 1998 qui se concentre sur les modeles de document 
XML et HTML, et fournit des fonctionnalites de navigation et de manipulation (voir figure 6-2). 
Une seconde edition est en cours d' elaboration (statut Draft de septembre 2000). 
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DOM Level 1 




Figure 6-2 

Organisation de DOM Level 1. 
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Figure 6-3 

Organisation de DOM Level 2. 
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• DOM Level 2 : recommandation de novembre 2000 qui s'appuie pleinement sur DOM Level 1. 
Les changements concement l'ajout d'un modele objet pour les feuilles de style, d'un modele evene- 
mentiel et la prise en charge des espaces de noms. Elle est decoupee en cinq sous-recommandations : 
Core, Views, Style, Events et Traversal-Range (voir figure 6-3). Une sixieme partie est en cours 
d' acceptation : HTML (statut Candidate Recommandation en juin 2002). 

• DOM Level 3 : recommandation en cours d'elaboration (statut Draft) qui s'appuie pleinement sur 
DOM Level 2. Les changements concement l'ajout des modeles de contenu (DTD et Schemas XML), 
des fonctionnalites de validation, de chargement et de sauvegarde des documents. 

II appartient aux editeurs d'implementer ou non ces specifications DOM, en particulier dans les 
navigateurs Internet : 

• Mozilla 1.0 implemente DOM1, DOM2 (des erreurs sont en cours de correction) et une petite 
partie de DOM3. 

• Microsoft Internet Explorer 6 implemente DOM1 . 



Implementations 

L'objectif premier de cette recommandation est de permettre I'ecriture de programmes generiques qui fonctionnent 
avec les logiciels de differents editeurs. En ce qui concerne les navigateurs, les dernieres versions implemented 
correctement DOM1 , mais il faut compter avec les anciennes versions qui sont toujours utilisees sur Internet et qui 
ne respectent pas pleinement les standards (Netscape 4.x, IE 5+, etc.). 



Dans la suite de ce chapitre, nous nous interesserons uniquement au noyau de DOM utilise pour les 
documents XML. 

Le noyau DOM2 XML 

DOM permet de structurer les documents XML sous forme d'une arborescence de nceuds. II fournit 
les methodes qui permettent de naviguer au sein de cet arbre et les interfaces qui permettent de 
manipuler les nceuds en fonction de leur type : element, attribut, texte, etc. 

La specification du noyau DOM definit : 

• les interfaces et les objets permettant de representer et manipuler un document ; 

• la semantique de ces interfaces et objets ; 

• les relations et collaborations entre ces interfaces et ces objets. 

L interface DocumentFragment 

DocumentFragment est un objet Document « allege » utilise pour representer des portions d' arborescences 
avec une implementation legere. Cet objet est de type Node. 

Cet objet n'a ni attribut, ni methode. 
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Linterface Document 

Document represente tout le document XML : il s'agit de la racine de l'arborescence. Cet objet est de 
type Node. 



Tableau 6-11. Attributs. 

Attribut Description 

documentEl ement L'element racine du document. 

doctype La declaration de la DTD associee au document. 

implementation L'objet DOMimplementation pour ce document. 



Tableau 6-12. Methodes. 



Methode 

createAttribute (attributeName) 
createAttributeNS (namespaceURI , qname) 

createCDATASection (text) 
createComment (text) 
createDocumentFragmentt ) 
createElement (tagName) 
createElementNS (namespaceURI, qname) 

create Entity Reference (referenceName) 
create Processing Instruction (target .text) 

createTextNode (text) 
getElementsByTagName (tagName) 

getElementsByTagNameNS (namespaceURI, lname) 

getElementsByld (id) 
importNode (newNode, bool ) 



Description 

Cree un nceud Attr (attribut) dont le nom est passe en argument. 

Cree un nceud Attr (attribut) dont le nom et I'espace de noms sont 
passes en argument (DOM2). 

Cree une CDATASection contenant le texte passe en argument. 

Cree un nceud commentaire contenant le texte passe en argument. 

Cree un objet DocumentFragment vide. 

Cree un nceud El ement dont le type est passe en argument (balise). 

Cree un nceud El ement dont le type (balise) et I'espace de noms 
sont passes en argument (DOM2). 

Cree un objet Enti tyRef erence dont le nom est passe en argument. 

Cree un nceud Processinglnstruction ayant le nom et les 
donnees passes en arguments. 

Cree un nceud Text contenant le texte passe en argument. 

Retourne un objet Node Li st (liste de noeuds) compose de tous les 
elements (El ement) de I'arbre dont le type est passe en argument. 

Retourne un objet Node Li st (liste de noeuds) compose de tous les 
elements (Element) de I'arbre dont le type (le nom local) et 
I'espace de noms sont passes en arguments (DOM2). 

Retourne un objet El ement dont I'identifiant est passe en argument 
(DOM2). 

Importe un objet Node ainsi que ses noeuds enfants ou non (DOM2J. 
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L interface Node 

Node est le type principal de donnees de DOM et represente un nceud de l'arborescence. 

Tableau 6-13. Les constantes. 



Constante 


Description 


ELEMENT_NODE 


Le nceud est un El ement. 


ATTRIBUTE_NODE 


Le nceud est un Attr. 


TEXT_N0DE 


Le nceud est un Text. 


CDATA_SECTION_NODE 


Le nceud est une CDATASection. 


ENTITY_REFERENCE_NODE 


Le nceud est une EntityReference. 


ENTITY_NODE 


Le nceud est une Entity. 


PROCESSING_INSTRUCTI0N_N0DE 


Le nceud est une Processing Inst ruction . 


C0MMENT_N0DE 


Le nceud est un Comment. 


DOCUMENTJIODE 


Le nceud est un Document. 


D0CUMENT_TYPE_NODE 


Le nceud est un DocumentType. 


DOCUMENT_FRAGMENT_NODE 


Le nceud est un DocumentFragment. 


N0TATI0N_N0DE 


Le nceud est une Notation. 



Tableau 6-14. Les attributs nodeName, nodeValue, et attributes ont des valeurs 
qui varient en fonction des types de noeuds. 



Type de noeud 


nodeName 


nodeValue 


attributes 


Element 


Le type de I'element (balise). 


null 


NamedNodeMap 


Attr 


Le nom de I'attribut. 


La valeur de I'attribut. 


nul 1 


Text 


#text 


Le contenu textuel du noeud. 


nul 1 


CDATASection 


#cdata-section 


Le contenu de la section CDATA. 


nul 1 


EntityReference 


Le nom de I'entite referencee. 


null 


nul 1 


Entity 


Le nom de I'entite. 


null 


nul 1 


Processing Inst ruction 


Lacible. 


Tout le contenu excepte la cible. 


nul 1 


Comment 


^comment 


Le contenu du commentaire. 


nul 1 


Document 


^document 


null 


nul 1 


DocumentType 


Le nom du type de document. 


null 


nul 1 


DocumentFragment 


#document-f ragment 


null 


nul 1 


Notation 

I 


Le nom de la notation. 


null 


nul 1 
1 
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Tableau 6-15. Attributs. 



Attribut 


Description 


attributes 


L'objet NamedNodeMap qui contient tous les attributs du nceud courant. 


childNodes 


L'objet NodeLi st qui contient tous les noeuds fils du nceud courant. 


fi rstChild 


Le premier nceud du nceud courant. 


lastChild 


Le dernier nceud du nceud courant. 


local Name 


Le nom local du nceud courant (DOM2). 


namespaceURI 


L'URI du nom d'espace de noms du nceud courant (DOM2). 


nextSibling 


Le nceud suivant qui a le meme parent. 


nodeName 


Le nom du nceud (voir tableau 6-14). 


nodeType 


Le type du nceud (voir tableau 6-1 4). 


nodeVal ue 


La valeur du nceud (voir tableau 6-1 4). 


ownerDocument 


L'objet Document. 


parentNode 


Le nceud parent. 


prefix 


Le prefixe du nceud courant (DOM2). 


previousSibl i rig 


Le nceud precedent qui a le meme parent. 



Methode 

appendChild (newChild) 

cloneNode (boolean) 
hasAttributes( ) 
hasChildNodes( ) 

insertBefore (newNode, refNode) 
isSupported (fonction, version) 

normal ize( ) 

removeChild (nodeName) 
replaceChild (newNode.oldNode) 



Tableau 6-16. Methodes. 

Description 

Ajoute le nceud (ou le DocumentFragment) a la fin de la listedes nceuds enfants 
du nceud courant. 

Retourne une copie exacte du nceud courant avec ou sans ses enfants (argument). 

Retourne vrai si le nceud courant a des attributs (DOM2). 

Retourne vrai si le nceud courant a des enfants. 

Insere le nceud (ou le DocumentFragment ) avant le nceud enfant passe en argument. 

Teste si la fonction passee en argument est prise en charge par I'implementation 
DOM dont la version est passee en argument (DOM2). 

Normalise I'arbre sous-jacent de I'element courant en s'assurant qu'il ne peut y 
avoir de nceuds de type texte consecutifs : les nceuds consecutifs sont remplaces 
par un nceud unique (DOM2). 

Supprime le nceud enfant dont le nom est passe en argument. 

Remplace un nceud enfant par un autre. 
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L interface NodeList 

NodeList est une collection ordonnee de nceuds, indexee a partir de zero. 



Attribut 

1 ength 



Methode 

item(index) 




Tableau 6-17. Attribut. 

Description 

Le nombre d'elements de la collection. 

Tableau 6-18. Met node. 

Description 

Retourne un element Node de la collection en fonction de sa position. 



L interface NameNodeMap 

NameNodeMap est une collection non ordonnee de nceuds adressables par leur nom, indexee a partir de zero. 



Attribut 

length 



Tableau 6-19. Attribut. 

Description 

Le nombre d'elements de la collection. 



Tableau 6-20. Methodes. 

Description 

Retourne un element Node de la collection, identifie par son nom. 

Retourne un element Node de la collection, identifie par son nom local 
et son espace de noms (DOM2). 

Ajoute un nceud identifie par son nom a la collection. 

Ajoute un nceud identifie par son nom et son espace de noms a la 
collection (DOM2). 

Supprime le nceud de la collection, identifie par son nom. 

removeNamedltemNS (namespaceURI , lname) Supprime le noeud de la collection, identifie par son nom local et son 

espace de noms (DOM2). 

item( index) Retourne un element Node de la collection en fonction de sa position. 



Methode 

getNamedltem (name) 

getNamedltemNS (namespaceURI, lname) 

setNamedltem (newNode) 
setNamedltemNS (newNode) 

removeNamedltem (name) 
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Linterface CharacterData 

CharacterData est une extension de l'interface Node. 



Tableau 6-21. Attributs. 



Attribut 




Description 


data 




Les donnees caracteres du nceud courant. 


length 




Le nombre de caracteres de I'attribut data. 


Tableau 6-22. Methodes. 


Methods 






substringDa 


ta (offset, cour 


t ) Retourne une extraction de la valeur caractere du nceud courant, d'une longueur 
et a partir d'une position passees en arguments. 


appendData 


(data) 


Ajoute une chaine de caracteres a la fin de la valeur du nceud courant. 


insertData 


(offset, data) 


Insere une chaine de caracteres dans la valeur du nceud courant, a la position 
donneeen argument. 


deleteData 


(offset, count) 


Supprime une partie de la valeur caractere du nceud courant, a la position et 
d'une longueur donnees en arguments. 


replaceData 


(offset, count. 


data) Remplace une partie de la valeur caractere du nceud courant, a la position et 
d'une longueur donnees en arguments, par une nouvelle chaine de caracteres. 



L'interface Attr 

Attr est un attribut de l'objet El ement. Cet objet est de type Node. 
Cette interface n'a pas de methode. 



Tableau 6-23. Attributs. 



Attribut Description 



name Le nom de I'attribut. 

specified Un booleen qui indique si une valeur a ete explicitement fournie pour I'attribut courant. 

val ue La valeur de I'attribut. 

ownerEl ement Le nceud de type element auquel appartient cet attribut (DOM2). 

L'interface Element 

El ement est un nceud de type element. Cet objet est de type Node. 

Tableau 6-24. Attribut. 



Attribut Description 

tagName Le nom du nceud (la balise). 
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Methode 

getAttribute (attributeName) 



Tableau 6-25. Methodes. 



Description 



getAttributeNS (namespaceURI , attributeName) 
get Attn' but eNode (attributeName) 
getAttributeNodeNS (namespaceURI, attributeName) 

getElementsByTagName (tagName) 

getElementsByTagNameNS (namespaceURI, tagName) 

hasAttributes (name) 

hasAttributesNS (namespaceURI, lname) 

normalizet ) 

removeAttribute (attributeName) 

removeAttributeNS (namespaceURI, attributeName) 

removeAttributeNode (attributeNode) 
setAttribute (attributeName, attributeVal ue) 

setAttributeNS (namespaceURI, qname, attributeVal ue) 

set AttributeNode (attributeNode) 
setAttributeNodeNS (attributeNode) 



Retourne la valeur de I'attribut de I'element courant dont le 
nom est donne en argument. 

Retourne la valeur de I'attribut de I'element courant dont le 
nom et I'espace de noms sont donnes en argument (DOM2). 

Retourne I'objet Attr qui correspond a I'attribut de I'ele- 
ment courant dont le nom est donne en argument. 

Retourne I'objet Attr qui correspond a I'attribut de I'ele- 
ment courant dont le nom et I'espace de noms sont donnes 
en argument (DOM2). 

Retourne un objet NodeLi st compose des elements dont 
le nom est donne en argument. L'ordre de la liste est celui 
des elements dans le document. 

Retourne un objet NodeLi st compose des elements dont 
le nom et I'espace de noms sont donnes en arguments. 
Lordre de la liste est celui des elements dans le document 
(DOM2). 

Retourne vrai si I'element courant a un attribut dont le 
nom est donne en argument (DOM2). 

Retourne vrai si I'element courant a un attribut dont le nom 
et I'espace de noms sont donnes en arguments (DOM2). 

Normalise I'arbre sous-jacent de I'element courant en 
s'assurant qu'il ne peut y avoir de noeuds de type texte 
consecutifs : les noeuds consecutifs sont remplaces par un 
nceud unique (DOM1). 

Supprime la valeur de I'attribut de I'element courant dont le 
nom est donne en argument. Insere une valeur par defaut 
si elle existe. 

Supprime la valeur de I'attribut de I'element courant dont le 
nom et I'espace de noms sont donnes en arguments. 
Insere une valeur par defaut si elle existe (DOM2). 

Supprime I'attribut de I'element courant. 

Insere un nouvel attribut dans I'element courant, dont le 
nom et la valeur sont fournis en arguments. 

Insere un nouvel attribut dans I'element courant, dont le 
nom, I'espace de noms et la valeur sont fournis en arguments 
(DOM2). 

Insere I'objet Attr fourni en argument dans I'element 
courant. 

Insere I'objet Attr fourni en argument dans I'element 
courant (DOM2). 
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L interface Text 

Text est le contenu textuel d'un nceud de type element ou attribut. Cet objet est de type CharacterData. 
Cette interface n'a pas d' attribut. 

Tableau 6-26. Methode. 



Methode Description 

splitText (offset) Cree un nouveau noeud adjacent apres avoir decoupe le contenu textuel a la position donnee en 
argument. 

Linterface Comment 

Comment est le contenu textuel d'un nceud de type element ou attribut. Cet objet est de type CharacterData. 
Cette interface n'a ni attribut, ni methode. 

Linterface CDATASection 

CDataSection est le contenu textuel d'un nceud de type CDATA. Cet objet est de type Text. 
Cette interface n'a ni attribut, ni methode. 

Linterface DocumentType 

DocumentType est le DTD associe au document. Cet objet est de type Node. 
Cette interface n'a pas de methodes. 

Tableau 6-27. Attributs. 



Attribut 


Description 


name 


Le nom de la DTD. 


entities 



Un objet NameNodeMap compose des entites generates internes ou externes. 


notations 


Un objet NameNodeMap compose des notations declarees dans la DTD. 


internalSubset 


Le sous-ensemble interne (DOM2). 


publ icld 


L'identificateur public de la DTD (DOM2). 


Systemld 


L'identificateur systeme de la DTD (DOM2). 



Linterface Notation 

Notation est une notation de DTD. Cet objet est de type Node. 
Cette interface n'a pas de methode. 

Tableau 6-28. Attributs. 

Attribut Description 

Publ icld L'identificateur public de la notation. 

Systemld L'identificateur systeme de la notation 
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L interface Entity 

Entity est une entite de DTD. Cet objet est de type Node. 
Cette interface n'a pas de methode. 

Tableau 6-29. Attributs. 

Attribut Description 

Publ i eld L'identificateur public de I'entite. 

Systemld L'identificateur systeme de I'entite. 

notati onName Le nom de la notation associee a I'entite pour les entites qui ne peuvent etre controlees. 

Linterface Processinglnstruction 

Processinglnstruction est une instruction de traitement. Cet objet est de type Node. 
Cette interface n'a pas de methode. 

Tableau 6-30. Attributs. 



Attribut 


Description 


Target 


La cible de I'instruction. 


Data 


Le contenu de I'instruction. 



Les analyseurs syntaxiques XML 

Les analyseurs syntaxiques (parsers) XML sont des programmes capables de parcourir et d'evaluer 
des documents XML. Lobjectif est bien evidemment de fournir au developpeur un moyen de mani- 
puler les documents XML par le biais d'une interface de programmation (API). Deux types d'API 
sont fournis par les analyseurs syntaxiques XML : 

• Une API conforme a la specification DOM (1 ou 2, et a Favenir 3) du W3C : cette API offre les 
fonctions de navigation et de manipulation de la structure arborescente du document XML. 

• Une API evenementielle appelee SAX pour Simple API for XML (http://www.saxproject.org) : cette API 
a ete creee au depart pour Java mais elle est maintenant disponible dans la plupart des langages. 
C'est un standard de facto. 

Les differences fondamentales entre ces deux API sont : 

• la premiere s'appuie sur un structure arborescente en memoire et permet une vision globale du 
document, alors que la seconde se contente de declencher des evenements (« debut document », 
« debut element paragraphe », « contenu », « fin element paragraphe », etc.) au fur et a mesure du 
chargement. La consommation memoire de SAX est done bien inferieure. 
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• la premiere necessite un chargement prealable et total du document pour permettre sa manipulation 
alors que la seconde permet de debuter le traitement immediatement. 

Les analyseurs syntaxiques XML se distinguent aussi en ce qui concerne la fonction de validation des 
documents XML : 1' implementation de XML Schema 1.0 est tres difficile, au point que beaucoup 
d' analyseurs syntaxiques ne sont compatibles qu'a 99 % avec la recommandation du W3C. 
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Echanger avec un service - 
Format du message 

Objets, services, documents 

Le 10 fevrier 1998, le World Wide Web Consortium (W3C) publie une « recommandation » remarquable : 
Extensible Markup Language (XML) 1.0. Des sa sortie, XML fait preuve d'une tres grande poly- 
valence, se pliant a des usages qui n'avaient probablement jamais effleure la fantaisie de ses premiers 
concepteurs. II devient rapidement le langage universel de description de donnees, structurees et non 
structurees. Aujourd'hui, les initiatives de normalisation en XML des donnees et des documents 
propres aux differents secteurs economiques, conduites par les organisations professionnelles et des 
organismes de normalisation, se comptent par centaines. Dans la lignee des grands standards Internet 
(IP, TCP, SMTP, HTTP, HTML. . .), XML devient incontournable. 

Tout de suite apres la publication de la recommandation, quatre architectes du logiciel : Dave Winer 
(UserLand Software), Don Box (DevelopMentor), Bob Atkinson et Mohsen Al-Ghosein (collabora- 
teurs de Microsoft) elaborent un protocole d'appel de procedure distante (de type RPC) qui utilise 
HTTP comme protocole de transport et XML comme format de message. Le resultat du travail est 
publie par Dave Winer en mars 1998 (a peine un mois apres la publication de la norme XML !) sous 
le nom de XML-RPC. A peu pres a la meme epoque, naissent et se developpent dans les laboratoires 
de R&D plus d'une dizaine d' experiences similaires, souvent dans la mouvance « RPC sur Internet 
par XML sur HTTP ». 



De nombreuses experiences RPC par XML sur HTTP 

Une liste, forcement incomplete mais assez nourrie, des specifications et des mises en oeuvre precoces des protoco- 
les d'echange et d'autres travaux preparatoires de la technologie des services Web est accessible sur http://www 
. w3. org/2000/03/29-XML-protocol-matrix. 
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XML-RPC 



Le principe de fonctionnement de XML-RPC (voir http://www.xmlrpc.com) est d'inclure : 

• dans le contenu associe a un POST (HTTP), une representation en XML de Fappel de procedure 
distante ; 

• dans la reponse au POST, une representation en XML du retour de Fappel. 

Lappel de procedure distante est encode comme contenu de type text/xml . Dans l'exemple qui suit, 
le client RPC invoque sur le serveur betty.userland.com la methode getStateName, avec en argument un 
entier de quatre chiffres (i4), lequel represente un code postal nord-americain : 

POST /RPC2 HTTP/1.0 

User-Agent: Frontier/5.1.2 (WinNT) 

Host: betty.userland.com 

Content-Type: text/xml 

Content-length: 181 

<?xml version="1.0"?> 

<methodCall> 

<methodName>examples.getStateName</methodName> 
<params> 
<param> 

<value><i4>4K/i4X/value> 
</param> 
</params> 
</methodCall> 

La reponse a l'execution reussie de la procedure est le nom de FEtat americain correspondant au 
code, represente par une chaine de caracteres, toujours encode comme contenu de type text/xml : 

HTTP/1.1 200 OK 
Connection: close 
Content-Length: 158 
Content-Type: text/xml 
Date: Fri, 17 Jul 1998 19:55:08 GMT 
Server: UserLand Frontier/5. 1.2-WinNT 
<?xml version="1.0"?> 
<methodResponse> 
<params> 
<param> 

<val ue><string>South Dakota</stringX/val ue> 
</param> 
</params> 
</methodResponse> 

XML-RPC est utilise aujourd'hui par une petite communaute de developpeurs qui lui sont restes fideles. 
Nous n'allons pas detailler dans cet ouvrage ses principes d'usage, par ailleurs tres simples. Cet 
exemple est presente seulement pour donner au lecteur une idee du fonctionnement du protocole. Ce 
qu'il faut retenir est que, derrieres les premieres initiatives de la mouvance que Ton appelle 
aujourd'hui « technologie des services Web », on trouve des architectes du logiciel qui veulent 
pouvoir effectuer des appels de procedures distantes sur Internet. 
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SOAP 



A partir de la publication de XML-RPC, l'activite autour des specifications et des technologies qui 
constituent aujourd'hui l'ensemble des « services Web », s'accelere et se diversifie. 

XML atteint rapidement une tres grande popularite et devient de plus en plus outille : 

• par des analyseurs syntaxiques de plus en plus rapides ; 

• par la disponibilite, dans plusieurs langages de programmation, de bibliotheques destinees a la 
manipulation des documents en memoire dont 1' interface programmatique est conforme au standard 
DOM (Document Object Model), recommandation W3C du 10 octobre 1998 ; 

• par la disponibilite d'outils complementaires, mais essentiels, comme XSLT. 

Par ailleurs, HTTP presente l'enorme avantage d'etre universellement accepte et mis en ceuvre. II est 
notamment plebiscite par une population professionnelle qui tient un role cle : les administrateurs 
reseau. En effet, ceux-ci maitrisent les techniques et les outils de securite et, de toute evidence, reservent 
un accueil mitige a Futilisation, a travers des pare-feu, d'autres protocoles IP (comme Internet Inter-ORB 
Protocol ou HOP specifie par FOMG et adopte par 1TETF, et comme Remote Method Invocation ou 
RMI, le protocole utilise pour la communication entre applications Java reparties). 

HTTP est un protocole simple, robuste et adapte au monde ouvert dTntemet. Evidemment, sa facilite 
d' utilisation et sa diffusion ont pour corollaire l'ouverture, qui est propre au Web « par defaut » et expose 
n'importe quelle application, au moins, au risque de la saturation des appels (denial of service). Par 
ailleurs, si une solution simple au probleme de la confidentialite des echanges est offerte par SSL sur 
HTTP (HTTPS), les solutions generalisees aux problemes de securite (authentification, autorisation, 
confidentialite, integrite, non-repudiation) sont aujourd'hui en developpement. 

XML-RPC est la source d'inspiration de SOAP (Simple Object Access Protocol), defini par une equipe 
issue de Microsoft, avec le concours de Dave Winer et Don Box. SOAP 1 .0 est presente sous la forme 
d'un Internet Draft, en novembre 1999, a l'lnternet Engineering Task Force (voir http://www.scripting 
.com/misc/soap1.txf). L'initiative semble rester confinee dans la mouvance Microsoft, mais debut 2000 
s'opere, sur le marche de la technologie, une dislocation de faille : IBM et sa filiale Lotus Development 
decident de travailler avec Microsoft arm de developper ensemble la version 1.1 de la specification 
SOAP, qui est ensuite consignee comme une note W3C en mai 2000 (voir http://www.w3.org/TR/SOAP). 

Outre Microsoft, IBM et sa filiale Lotus, un nombre important de societes appuient cette soumission 
parmi lesquelles : Ariba Inc., Commerce One Inc., Compaq Computer Corporation, DevelopMentor 
Inc., Hewlett Packard Company, IONA Technologies, SAP AG, UserLand Software Inc.). La W3C 
note du 8 mai 2000 : Simple Object Access Protocol (SOAP) 1.1, est completee par une note supple- 
mentary du 11 decembre 2000 : SOAP Messages with Attachments, qui traite de l'inclusion de pieces 
jointes aux messages SOAP par l'utilisation de la structure multipartie MIME (multipart), utilisee sur 
Internet pour vehiculer des documents heterogenes (voir http://www.w3.org/TR/SOAP-attachments). 

Cette evolution permet le veritable demarrage de la technologie des services Web. IBM, un des 
acteurs majeurs de l'industrie informatique, est deja fortement engage dans la normalisation et la 
mise en ceuvre du langage Java, des architectures fondees sur ce langage et notamment de Java 2 
Enterprise Edition (J2EE). L architecture J2EE est clairement destinee a la mise en ceuvre de systemes 
d' e-business et d' informatique de gestion et constitue le fer de lance technologique d'une coalition 
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heterogene dont l'objectif strategique avoue est de contrer l'expansion de Microsoft dans le domaine 
des technologies logicielles ayant trait aux serveurs. 

Maintenant, IBM coopere, avec son concurrent historique Microsoft, sur la definition d'un standard 
d'echange et d'interoperabilite sur le Web entre applications informatiques, mises en ceuvre sur des 
technologies qui sont, par construction, heterogenes. La presence d'IBM, qui mise fortement sur la 
technologie Java, aux cotes de Microsoft, qui va proposer un mois apres la nouvelle architecture 
d' applications .NET - a son tour concue et presentee comme la reponse de Microsoft a J2EE - credi- 
bilise la promesse d'interoperabilite entre services Web batis sur des architectures et des technologies 
radicalement differentes et concurrentes. 

En effet, le simple fait qu'un protocole d'echange interapplications Web repose sur deux standards 
universellement acceptes, comme XML et HTTP, ne suffit pas pour autant a garantir l'independance 
de ce protocole des technologies mises en ceuvre dans les applications qui l'utilisent. SOAP 1.1 
permet l'echange entre applications construites sur des technologies heterogenes, parce qu'il a ete concu 
pour cela. 

Par ailleurs, les propres limites d'interoperabilite du protocole SOAP, qui resultent de derives 
proprietaries d' interpretation de specifications, auxquelles nous consacrons une partie du chapitre 17 
de cet ouvrage, montrent bien la difficulte paradoxale a assurer la tenue de l'engagement d'interope- 
rabilite d'une technologie, dont il s'agit la du postulat principal. Ces limites donnent la mesure de la 
distance qui separe la publication d'un document de specification, de sa mise en ceuvre a grande 
echelle. 

La difference avec les tentatives passees de normalisation reside dans le fait que la technologie des 
services Web affiche comme objectif fondamental et pratiquement unique d'assurer l'interoperabilite 
des applications. Lelargissement du marche des services Web passe done par la tenue de cette 
promesse : d'ou la necessite, de la part des fournisseurs de technologies de se proteger contre toute 
tentation de fermeture et de consacrer un effort important et specifique pour atteindre l'objectif. La 
mise en place, en fevrier 2002, de l'initiative Web Service Interoperability (WS-I) de la part d'IBM, 
Microsoft, BEA, Intel, et autres montre bien 1' importance et l'urgence de veiller en permanence a la 
convergence vers cet objectif pour permettre le decollage du marche des services Web. 

SOAP est, a l'origine, l'acronyme de Simple Object Access Protocol, le protocole « simple » d'acces 
aux objets. Le nom ne correspond pas a l'objet nomme et est meme deroutant : SOAP n'est en aucun 
cas un protocole de dialogue entre objets repartis. II ne permet pas de s'adresser directement a un objet 
distant, meme s'il peut evidemment etre utilise indirectement pour aboutir a ce resultat. 

SOAP n'est done pas un protocole « objet » : ce choix technique n'est pas un accident, ni le produit 
de la meconnaissance ou de l'hostilite pour l'approche « objet », mais bien une volonte precise des 
concepteurs de SOAP, lesquels sont tous des experts des architectures a objets repartis. En fait, la 
« non-objectivite » de SOAP est un trait indispensable pour garantir les caracteristiques essentielles 
d'independance des implementations et d'interoperabilite des services Web. 

Objets par reference 

Pour envoyer un message a un objet distant, l'emetteur doit d'abord connaitre l'identifiant unique de 
cet objet sur le reseau. A partir du moment ou la reference a un objet existant dans la memoire d'un 
processus sort de l'espace d'adressage du processus pour se diffuser sur un reseau, commence a se 
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poser un ensemble de problemes dont la solution, par ailleurs techniquement delicate, depend ineluc- 
tablement des caracteristiques du langage utilise, ainsi que des strategies des compilateurs et des 
environnements d'execution (interpreteurs, gestionnaires de la memoire) en jeu. En un mot, ils 
dependent de la mise en ceuvre des interlocuteurs de Fechange. 

Par ailleurs, l'exportation de la reference d'un objet en dehors de son espace d'adressage pose des 
problemes pratiquement insolubles dans une architecture ouverte. A quel moment liberer la memoire 
allouee a un objet, lorsque son identifiant voyage sur le reseau ? A quel moment decider que la retention 
de 1' identifiant sur le reseau n'est pas un oubli, un abus ou un acte hostile, mais la necessite d'une 
transaction longue ? Evidemment, ces questions ont des reponses plus ou moins faciles pour un 
systeme dont la repartition sur un reseau local ferme a ete imaginee en detail par le concepteur et est 
strictement controlee en execution par Fadministrateur, mais qu'en est-il dans le monde ouvert d'Internet ? 

En tout etat de cause, meme sur un reseau local, dans un monde ferme et controle, ces problemes et 
d'autres connexes se sont reveles, dans la pratique, difficilement solubles. La plupart des applications 
reparties ont ete mises en ceuvre sur la base d'une approche que nous appelons service. Les deux 
approches se sont affrontees dans la mise en ceuvre d' applications reposant sur l'architecture client/ 
serveur : 

• L' approche objet pur veut que l'application cliente obtienne Y identifiant technique (un IOR : 
Internet Object Reference, dans le monde CORBA/IIOP) de la copie en memoire du serveur de 
Finstance de laclasse Contrat, parexemple, ayant comme valeurde Fattribut numeroContrat la valeur 
123456 (numeroContrat est la cle applicative du contrat). Ensuite, l'application cliente peut appliquer 
directement a Fobjet distant via son identifiant des methodes comme obteni rLeNomDuContractant. 

• L' approche service, consiste a appeler, sur l'identifiant technique d'une instance de la classe 
Gesti onDesContrats {singleton), « composant » qui fait office de representant du service de gestion 
des contrats en execution la methode obteni rLeNomDuContractant, avec comme argument la valeur 
23456, identifiant metier du contrat en question. Rien n'empeche a F implementation de l'application 
de deleguer la requete a Finstance de Fobjet contrat approprie, ou de choisir toute autre organisation 
alternative. L'identifiant du service (de Finstance singuliere de la classe Gesti onDesContrats qui 
represente le service) est utilise dans ce contexte comme le point d'entree du service. 

A Fusage, c'est la deuxieme approche qui a ete largement utilisee dans les applications client/serveur 
mises en ceuvre avec des langages objet. II est evident qu' appeler cette organisation « architecture 
d'objets repartis », meme si le langage de programmation est « objet », est un abus de langage : il 
s'agit de la pratique usuelle d' invocation de procedures distantes (RPC ou Remote Procedure Call) 
entre applications jouant respectivement les roles de client et de serveur sur deux nceuds distants du 
reseau. Le fait que les applications impliquees soient ou non mises en ceuvre en utilisant des langages 
objet est transparent par rapport au protocole d'echange. 

Remonter de la granularite de deploiement de Fobjet Contrat a celle du service Gestion de contrats 
simplifie le deploiement et F exploitation, car cela pose une couche d' abstraction qui cache aux 
clients de l'application de gestion des contrats la connaissance des details d' implementation (par 
exemple, la gestion des instances de la classe Contrat, de leurs identifiants techniques, de la memoire 
allouee et de sa liberation). Pour ces raisons, une grande partie des applications client/serveur mises 
en ceuvre au moyen de langages objet ont choisi d'exposer comme interlocuteur de l'appel distant 
une granularite de type « service » plutot qu'« objet ». Par ailleurs, lorsque le langage d' implementation 
n'est pas « objet », l'approche « service » s'impose naturellement. 
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Objets par valeur et documents 

La difficulte a traiter les objets par reference dans les architectures reparties est a l'origine des 
developpements effectues pour permettre le passage des objets par valeur. A partir du moment ou, 
pour des raisons de performance, de fiabilite et de robustesse de 1' application, il est deconseille de 
manipuler un objet distant par une suite d' operations a granularite fine, il est tentant de transferer 
l'objet directement afin de le manipuler en local. Par exemple, lorsqu'on negocie un contrat, il semble 
naturel de transferer entre contractants la copie du contrat, chacun apportant ses modifications, jusqu' a 
convergence sur un objet commun. 

Pour repondre a cette exigence de transfert entre applications reparties, il est indispensable de definir, 
en plus de la convention de codage de types atomiques (entier, chaines, etc.) necessaire pour transferer 
les valeurs des arguments de Fappel de methode sur des objets distants, une regie de « serialisation » 
de structures complexes. 

Ce qui est vehicule est bien, a premiere vue, une structure de donnees et non un objet. Un objet est, 
par definition, une structure de donnees et un ensemble de traitements associes. La mise en ceuvre 
effective de F invocation de methodes distantes avec passage d' objets par valeur, necessite au moins 
deux prerequis : 

• que le client et le serveur soient capables d'encoder et de decoder dans un message de requete/ 
reponse la structure de donnees representant l'objet passe en argument ; 

• que le client et le serveur soient capables de manipuler l'objet reconstruit, a savoir que le code des 
methodes de manipulation de l'objet leur soit egalement accessible. 

Ces deux prerequis ne peuvent etre entierement satisfaits qu'a deux conditions : 

• Le client et le serveur doivent etre mis en ceuvre en utilisant le meme langage de programmation et 
le meme environnement de compilation et d' execution de ce langage. C'est seulement a ce prix 
que le passage d'objets par valeur prend tout son sens. 

• Le client et le serveur doivent etre capables de partager sur le reseau les codes des methodes 
applicables a l'objet. 

Ces deux conditions sont plus contraignantes que celles necessaires a F invocation de methodes 
distantes avec passage d'objets par reference, qui se limitent : 

• au codage de Fappel ; 

• au codage des identifiants universels des objets ; 

• au codage des donnees atomiques. 

Le passage d'objets par reference peut etre effectue entre programmes mis en ceuvre par des langages 
de programmation differents (par exemple utilisant le meme ORB dans une architecture CORBA). 

Le passage d'objets par valeur necessite l'homogeneite des environnements de mise en ceuvre et le 
partage de code entre le client et le serveur. Sans ces deux conditions, la structure passee est une 
structure de donnees, et les procedures d'encodage/decodage et les methodes de manipulation sont 
differentes entre client et serveur. 

Cette derniere approche est appelee approche document : la structure de donnees dans la requete et la 
reponse est un « document » qui est encode, decode, manipule de facon independante par le client et 
le serveur. Assurement, le client et le serveur partagent (ou ont l'impression de partager) la semantique 
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informelle du document (une commande, une facture, etc.) meme si les semantiques operationnelles 
sont differentes. 

SOAP et l'utilisation de XML pour le contenu des messages vont normaliser l'approche document. 
Service Oriented Access Protocol ? 



Noah Mendelsohn (Lotus Development Corporation), un des auteurs de la specification SOAP 1.1, rappelle avec 
amusement, dans un courrier electronique envoye a une liste de distribution SOAP (SOAP@DISCUSS.DEVELOP 
.COM), I'embarras de I'equipe de specification par rapport a I'acronyme herite de SOAP 1 .0 (Simple Object Access 
Protocol), ainsi que la recherche a rebours d'autres noms etendus plus appropries, comme « Service Oriented 
Access Protocol ». 

Ce dernier nom etendu nous semble parfait, mais n'a finalement pas ete retenu. L'acronyme SOAP a ete conserve 
en gage de continuite avec SOAP 1.1, mais il devient, a partir de SOAP 1.2, un simple nom propre, qui ne garde 
plus aucune relation de sens avec I'acronyme d'origine. II est dommage que I'activite Web Services du W3C (voir 
http://www.w3.org/2002/ws), en charge de la normalisation, n'ait pas eu la determination d'imposer comme nom 
etendu « Service Oriented Access Protocol », dont la pertinence et la puissance semantique auraient probablement 
eu une influence favorable sur la comprehension et la diffusion de la technologie des services Web. 



Un protocole d'echange sur le Web doit exhiber au moins trois proprietes pour garantir Finteroperabilite 
des applications a implementations heterogenes : 

• II doit etre totalement compatible avec les technologies, les outils et les pratiques courantes sur 
Internet. Le protocole doit etre egalement evolutif, done compatible, mais relativement independant 
des technologies et des pratiques du reseau d'aujourd'hui, et capable d'integrer facilement leurs 
evolutions. 

• II doit etre totalement independant des specificites de mise en ceuvre des applications. Notamment, 
le protocole doit etre independant des systemes d' exploitation, des langages de programmation, 
des environnements d' execution, des eventuels modeles de composants logiciels utilises. 

• II doit etre « leger » ou, plus precisement, « non intrusif ». Non seulement les implementations des 
applications qui participent a Fechange ne sont en aucun cas obligees de connaitre les implemen- 
tations de leurs interlocuteurs, mais, en plus, aucune installation de technologie dependante des 
choix d' implementation des interlocuteurs ne doit etre requise pour correspondre avec eux. Ce qui 
est necessaire pour echanger est la technologie logicielle permettant d'encoder, d'emettre, de 
receptionner et de decoder des messages qui ont un format universel et normalise. Cette technologie 
est evidemment specifique, voire proprietaire, pour chaque environnement ou langage d' implemen- 
tation, mais reste totalement independante des technologies d' implementation des applications 
interlocutrices. 

SOAP 1.1, ainsi que les travaux en cours sur son successeur SOAP 1.2, satisfont globalement ces 
exigences. Plus precisement, SOAP 1.1 est aujourd'hui une technologie parfaitement utilisable et 
largement mise en ceuvre. 

A la soumission de SOAP 1.1 a suivi F initialisation, en septembre 2000, d'un groupe de travail du 
W3C (XML Protocol) qui aujourd'hui se charge de normaliser Fensemble croissant des technologies 
d'echange entre applications distributes reposant sur XML. Ce groupe de travail s'applique, entre 
autres, a la specification SOAP 1.2. 
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En Janvier 2002, a demarre au sein du W3C l'activite Web Services, qui couvre desormais F ensemble 
des technologies et des protocoles d' interaction d' applications reparties sur le Web. Cette activite 
absorbe le groupe de travail XML Protocol et continue les travaux de normalisation de SOAP 1.2, et 
demarre en outre d'autres travaux qui touchent d'autres technologies de services Web, au-dela de 
l'echange, et notamment le niveau description avec WSDL (Web Services Description Language). 



Les ressources sur le site Web du W3C 

La specification SOAP 1.1, detaillee dans le reste du chapitre est publiee dans le document : Simple Object 

Access Protocol (SOAP) 1. 1 - W3C Note 08 May 2000 ; http://www.w3.org/TR/SOAP. 

Pour suivre l'activite de la Web Services Activity du W3C : http://www.w3.org/2002/ws. 

Pour suivre revolution des protocoles d'echange : http://www.w3.org/2000/xp/Group. 

Les documents produits par le groupe de travail sont tous a I'etat de draft au moment de la redaction de cet 

ouvrage. En voici la liste : 

- XML Protocol Requirements : http://www.w3.org/TR/xmlp-reqs ; 

- XML Protocol Usage Scenarios : http://www.w3.org/TR/xmlp-scenarios ; 

- XML Protocol Abstract Model : http://www.w3.org/TR/xmlp-am ; 

- SOAP Version 1.2 Part 1 - Messaging Framework : http://www.w3.org/TR/soap12-part1 ; 

- SOAP Version 1.2 Part 2- Adjuncts : http://www.w3.org/TR/soap12-part2 ; 

- SOAP Version 1.2 Part - Primer : http://www.w3.org/TR/soap12-part0 ; 

- SOAP Version 1.2 Specification Assertions and Test Collection :http://www.w3.org/TR/soap12-testcollection ; 

- OAP 1 .2 Attachment Feature : http://www.w3.org/TR/soap12-af \ 

- SOAP Version 1.2 Email Binding : http://www.w3.org/TR/soap12-email. 

Nous allons maintenant presenter SOAP 1.1. Nous soulignerons au fur et a mesure les differences avec SOAP 1 .2 
(a I'etat de candidate recommandation au moment de la redaction de cet ouvrage). 



Validation et verification de linteroperabilite 

Linteroperabilite theorique de SOAP et des autres technologies de services Web ne fait pas de doute. 
Linteroperabilite pratique demande des activites de validation et de verification des differentes 
implementations. C'est ce qui avait manque aux implementations CORBA, et ces activites font partie 
integrante de la tache que se donne le WS-I (Web Services Interoperability Organization), consortium 
d'industriels et d'utilisateurs. 

La methode adoptee par le WS-I est de travailler par « profils ». Un profil est un ensemble coherent 
de technologies de services Web a un certain niveau de version. Des le demarrage de l'organisation, 
un profil de base est defini (Basic Profile), comprenant les quatre technologies auxquelles est consacree 
une grande partie de ce livre : XML Schema 1.0, SOAP 1.1, WSDL 1.1 et UDDI 2.0. 

Le 8 octobre 2002, le WS-I a publie Basic Profile Version 1.0 - Working Group Draft (http://www.ws-i.org 
/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm), un document qui contient cent recommandations permettant 
de garantir l'interoperabilite de F usage des technologies de services Web conformes a ce profil de 
base. 

Nous allons voir, au fur et a mesure de la presentation des traits de SOAP 1.1, les preconisations du 
groupe de travail WS-I. 
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La logique des recommandations de I'lETF, du W3C et du WS-I 

La logique des obligations pour les implementeurs utilisee dans les documents de specifications (recommandations) 
de deux organisations cles pour la technologie des services Web (W3C, WS-I) est la meme. Elle reprend celle 
formalisee dans le document IETF RFC21 1 9 (voir http://www.ietf.org/rfc/rfc21 19.txt). C'est une logique a cinq niveaux : 

- Obligatoire : les mots-cles anglais sont MUST, SHALL, REQUIRED, dans notre texte nous utiliserons les formes 
« doit », « il est requis », « obligatoire », etc. 

- Recommande : les mots-cles anglais sont SHOULD, RECOMMENDED, dans notre texte nous utiliserons les 
formes « devrait », « recommande »... Ilfautnoterquecetteforced'obligationn'estpasaconfondreavecleterme 
« recommandation » qui est utilise pour designer un document enterine de specification du W3C ou pour I'une des 
cent « recommandations » du profil de base WS-I. 

- Optionnel : les mots-cle anglais sont MAY, OPTIONAL, dans notre texte nous utiliserons « peut », « optionnel », 
« permis », etc. 

- Deconseille : les mots-cles anglais sont SHOULD NOT, NOT RECOMMENDED, dans notre texte nous utiliserons 
« ne devrait pas », « deconseille », etc. 

- Interdit : les mots-cles anglais sont MUST NOT, SHALL NOT, dans notre texte nous utiliserons les formes « ne 
doit pas », « interdit », etc. 

La comparaison avec la logique binaire « licite/illicite » est que ce qui est illicite est interdit, tandis que ce qui est 
licite peut etre obligatoire, recommande, permis ou deconseille (avec la nuance qu'il est illicite de ne pas assurer le 
niveau obligatoire). Un implemented doit mettre en ceuvre ce qui est obligatoire et ne doit pas implementer ce qui 
est interdit. II est dans le domaine du choix totalement libre pour ce qui est optionnel, et doit evaluer avec soin les 
consequences de ne pas faire ce qui est recommande et de faire ce qui est deconseille. 
Empiriquement, il faut constater que cette logique, qui est sans doute complexe, « lache » et peut paraitre source 
de problemes d'interoperabilite, a bien reussi dans la pratique : Internet et le World Wide Web en sont la preuve. II 
est trop tot pour juger de son adequation a une technologie comme celle des services Web, dont I'objectif est 
I'automation de I'echange entre systemes heterogenes. 



Les principes du protocole SOAP 1.1 

SOAP 1.1 fournit un mecanisme qui permet d' echanger de F information structuree et typee entre 
applications dans un environnement reparti et decentralise. II ne vehicule pas de modele de program- 
mation ou d'implementation, mais foumit les outils necessaires pour definir des modeles operationnels 
d'echange (styles d'echange) aussi diversifies que les systemes de messagerie asynchrone et Yappel 
de procedure distante (RPC). 

SOAP 1.1 specifie l'utilisation de documents XML comme messages. Pour ce faire, il possede un 
certain nombre de traits : 

• une grammaire pour definir le format et la structure des messages (en termes de documents XML) ; 

• une convention pour designer les agents logiciels habilites a traiter les differentes parties du 
message ainsi que le caractere obligatoire ou optionnel du traitement ; 

• une representation codee pour vehiculer les donnees atomiques et structurees manipulees par les 
langages de programmation (style de codage) ; 

• un ensemble de consignes (liaison « generique ») pour transporter les messages sur le protocole de 
transport HTTP ; 
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• une representation de la requete et de la reponse d'un appel de procedure distante (RPC) ; 

• un ensemble de consignes supplementaires pour transporter des messages accompagnes de documents 
heterogenes en pieces jointes. 

Tous ces traits font partie de SOAP 1.1, mais sont fonctionnellement modulaires et orthogonaux. II 
faut noter que SOAP 1.1 est redefinis sable, car il contient les mecanismes necessaires a la definition 
de specifications alternatives pour ces traits, et extensible, car il permet de definir et d'ajouter des 
traits supplementaires au mecanisme de base. 

Nous examinerons dans ce chapitre la grammaire du message et les conventions de traitement, ainsi 
que le style d'echange par message unidirectionnel, avec eventuellement des intermediaries dans la 
chaine d'acheminement. 

La problematique du codage des donnees, des styles de codage, ainsi que la transmission de documents 
heterogenes (objets multimedias) en tant que pieces jointes seront exposees dans le chapitre 8. 

Enfin, nous aborderons la problematique des styles d'echange (message a sens unique, requete/reponse, 
appel de procedure distante), ainsi que la liaison SOAP/HTTP dans le chapitre 9. 

La structure de la specification SOAP 1. 1 

La structure de la specification SOAP 1.1 est representee a la figure 7-1. La specification peut etre 
organisee sur plusieurs niveaux {echange, format, contenu, liaison). Elle prevoit une pluralite de styles 
d'echange possibles, qui reposent tous sur un seul et unique (quoique extensible)/ormaf de message : 
le format XML de Fenveloppe SOAP 1.1 et de ses elements descendants. 

Le message a format unique peut heberger un contenu litteral (du XML bien forme ou valide par 
rapport a des schemas XML Schema) ou code (en suivant une pluralite de styles de codage) et faire 
l'objet d'un ensemble de conventions de liaison {binding) avec une pluralite de protocoles de 
transport. Les parties grisees du diagramme 7-1 constituent l'objet de la specification SOAP 1.1. 

Le format de message constitue le pivot de la specification. Le message peut etre transfere par 
plusieurs protocoles de transport et dans le cadre de plusieurs styles d'echange entre applications. 
Certains protocoles de transport peuvent etre particulierement appropries pour certains styles d'echange. 
C'est typiquement le cas du style RPC, qui repose sur une specialisation du format de message, even- 
tuellement sur un style de codage. Le style RPC donne des consignes de liaison particulieres qui lient 
directement le fonctionnement appel/retour du style d'echange RPC avec le fonctionnement requete/ 
reponse du protocole de transport HTTP. 
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Figure 7-1 

Structure de la specification par niveaux de SOAP 1.1. 
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Protocole HTTP et couche de transport 

II est un peu abusif de parler de HTTP comme d'un protocole de transport alors que le niveau transport est occupe 
dans la pile IP par TCP et UDP. Nous continuerons a le faire pour simplifier la presentation, en sachant que, du 
point de vue SOAP, HTTP est effectivement un moyen de transport de messages. 



Les usages standards et etendus de SOAP 1.1 sont presentes figure 7-2. 
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Figure 7-2 

Les usages de base et etendus de SOAP 1.1. 

Les bases de SOAP 1 .1 

Nous avons vu que les styles d'echange proposes par SOAP 1.1 sont le message a sens unique et la 
requete/reponse, avec ses deux variantes document et RPC. 

Le message a sens unique est presente dans ce chapitre, alors que le style requete/reponse (document 
et RPC) est presente dans le chapitre 9. 

Un message a sens unique SOAP 1.1 part d'un nceud expediteur pour atteindre un nceud destinataire 
(figure 7-3). 



Expediteur 




Destinataire 



Figure 7-3 

Style d'echange message a sens unique. 
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Voici un exemple de message : 

<?xml version="1.0" encoding="UTF-8"?> 
<Envelope 

xmlns=" http://schemas.xml soap.org/soap/envelope/"> 
<Body> 

<Greeting> 

<text>Ciao !</text> 
</Greeting> 
</Body> 
</Envelope> 

Un message peut etre transfere directement de l'expediteur au destinataire, ou bien transiter par un 
nombre illimite de nceuds intermediaires qui forment une chaine d ' acheminement (figure 7-4). 
Chaque nceud intermediaire est recepteur du message emis du nceud precedent dans la chaine et 
emetteur du message pour le nceud suivant. Dans une chaine d' acheminement, l'expediteur est le 
premier emetteur et le destinataire est le dernier recepteur. Un nceud intermediaire est une application 
SOAP 1.1 capable de receptionner et d'emettre des messages SOAP 1.1. 
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Figure 7-4 

Une chaine d 'acheminement. 

L'utilite du mecanisme de la chaine d' acheminement est a la fois technique et fonctionnelle. Du point 
de vue technique, le mecanisme normalise le role et la fonction du routeur applicatif. Du point de vue 
fonctionnel, les possibilites offertes par ce mecanisme sont multiples. II permet de composer des 
services tiers sur la base de fonctions reparties sur la chaine d' acheminement, comme F annotation des 
messages, Fabonnement, la confidentialite par chiffrement, la mise en cache ou stockage intermediaire 
(caching), la non-repudiation. 

Les differents elements d'un message SOAP 1.1 sont produits et consommes par les nceuds de la 
chaine d' acheminement. Produire un element d'un message revient a le constituer. Consommer un 
element d'un message equivaut a le traiter et, pour les intermediaires, a reemettre le message apres 
avoir supprime l'element consomme. Le producteur d'un element d'un message SOAP 1.1 est le 
nceud (expediteur ou intermediaire) qui produit l'element en question (ainsi que tous ses sous- 
elements). Le consommateur d'un element d'un message SOAP 1.1 est le nceud (intermediaire ou 
destinataire) qui consomme l'element en question (ainsi que tous ses sous-elements). 
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L'expediteur du message est le premier producteur du message. Le recepteur du message, qu'il soit 
intermediaire ou destinataire, doit exhiber un comportement normalise, qui peut etre resume ainsi : 

1. II doit examiner le message pour chercher les informations qui lui sont destinees. 

2. Parmi les parties du message qui lui sont adressees, il y en a certaines dont la consommation de 
la part du nceud est obligatoire : si le nceud est « capable » d'effectuer cette consommation, il doit 
l'effectuer, et s'il n'en est pas « capable », il doit rejeter le message. 

3. S'il s'agit d'un intermediaire, alors il doit supprimer du message les parties qu'il consomme, et il 
peut ainsi produire des elements nouveaux, poses dans les endroits du message destines a cet 
effet, puis il doit emettre a nouveau le message vers le nceud suivant de la chaine d'acheminement. 

SOAP 1.1 et XML 

Le message SOAP 1.1 est un document XML 1.0. Cela implique qu'un document XML 1.0 ne peut 
pas etre insere tel quel dans un message SOAP 1.1 (un document XML ne peut pas etre insere sans 
changement dans un autre document XML). La specification SOAP 1.1 ne confirme pas explicitement 
si un message SOAP 1.1 doit debuter par la declaration d'usage : 

<?xml version="1.0" ...?> 



RecommandationsWS-l Basic Profile 1.0 (draft) 

La presence de la declaration XML (<?xml version="1.0" ...?>) est facultative (R1010). La presence ou 

I'absence d'une telle declaration n'a pas d'impact sur I'interoperabilite des implementations. 

Pour cause d'interoperabilite, il est preferable que les messages soient encodes en UTF-8 ou UTF-16 (R1012). 



La specification de SOAP 1.1 etablit qu'un message SOAP 1.1 : 

• ne doit pas contenir de DTD (Document Type Definition), cela essentiellement pour la raison technique 
que la syntaxe des DTD n'est pas au format XML ; 

• ne doit pas contenir destructions executables, dont la presence est acceptee dans les documents 
conformes a XML 1.0. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Le profil de base 1 .0 WS-I (draft) confirme explicitement les interdictions de DTD et d'instructions executables dans 
un message SOAP (R1008, R1009). 



L utilisation generalisee des vocabulaires XML (XML Namespaces) et des noms qualifies est fortement 
conseillee par la specification SOAP 1.1, quoique non obligatoire pour une application qui joue 
seulement le role d'expediteur de messages. En revanche, les applications qui pretendent jouer le role 
de destinataire doivent etre capables de traiter correctement les vocabulaires XML des messages 
qu'elles recoivent. Ces applications doivent rejeter les messages qui utilisent les vocabulaires XML 
de facon incorrecte ou qui utilisent des vocabulaires XML incorrects. 

La specification SOAP 1.1 definit un vocabulaire XML SOAP 1.1 pour les elements et les attributs 
propres au format du message. L'identifiant du vocabulaire XML SOAP 1.1 est associe a l'URI 
http://schemas .xml soap.org/soap/envelope/. 
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La declaration du vocabulaire XML http://schemas.xmlsoap.org/soap/envelope/ est obligatoire 
pour tout message SOAP 1.1. Cette declaration designe la version de SOAP revendiquee par le message. 

Le prefixe associe au vocabulaire XML http://schemas.xmlsoap.org/soap/envelope/ dans la specifi- 
cation SOAP 1.1 est SOAP-ENV. Le bon usage des vocabulaires XML (lorsqu'un prefixe est utilise par 
une specification dont les elements sont utilises dans un document, il est preferable d'utiliser le 
meme prefixe que la specification) suggere que dans F element racine (SOAP-ENV Envelope) de tout 
message SOAP 1.1 apparaisse la declaration : 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envel ope/" 

Un message SOAP 1.1 peut integrer des declarations de vocabulaires XML applicatifs quelconques. 

Lexemple presente dans le paragraphe precedent, lorsqu'il integre les declarations de vocabulaires 
XML et F usage des noms qualifies, prend Failure suivante (le vocabulaire XML designe par le 
prefixe g est un vocabulaire applicatif) : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns: SOAP- ENV="http://schemas .xml soap.org/soap/envel ope/"> 
<SOAP-ENV:Body> 

<g: Greeting xml ns:g="http: //www. greetings.org/greetings/"> 

<g:text>Ciao !</g:text> 
</g:Greeting> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

L'utilisation des attributs est egalement normalisee. II est admis d'introduire des attributs dans les 
elements d'un message SOAP 1.1. Ces attributs peuvent etre directement integres dans les occurrences 
des elements d'un message ou peuvent etre specifies dans un schema XS ou une DTD accessible 
aussi bien a l'expediteur qu'au destinataire. Dans ce cas, les valeurs, par defaut ou fixes, definies dans 
le schema XS ou la DTD doivent etre prises comme s'elles apparaissaient directement dans les 
instances. Les attributs SOAP-ENV:mustUnderstand et SOAP-ENV:actor sont introduits par la specification 
SOAP 1.1 et jouent un role particulier qui sera examine par la suite. 

La structure du message SOAP 1 .1 

Un message SOAP 1.1 presente une structure normalisee (voir figure 7-5). II est toujours constitue 
d'un element « document » (racine), a savoir Venveloppe (SOAP-ENV: Envelope), qui contient un 
element en-tete (SOAP-ENV:Header) optionnel et un element corps (SOAP-ENV:Body) obligatoire, suivis 
d'eventuels elements applicatifs specifiques. 
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Figure 7-5 

La structure du message SOAP 1.1. 
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L'enveloppe 

L'enveloppe est F element « document » (ratine) de tout message SOAP 1.1. 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- ENV="http://schemas. xmlsoap.org/soap/envel ope/" 

</SOAP-ENV:Envelope> 

Dans l'enveloppe d'un message SOAP 1.1, la presence de la declaration du vocabulaire XML SOAP 1.1 
est obligatoire : 

xmlns: SOAP -ENV="http: //schemas .xml soap.org/soap/envelope/" 

ou, eventuellement : 

xml ns=" http://schemas.xml soap.org/soap/envel ope/" 
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Cette declaration est utilisee pour marquer la version SOAP (SOAP 1.1) a laquelle le message fait 
reference. Le message s' attend ainsi a etre traite par tout recepteur (intermediate ou destinataire) 
selon la version du protocole qu'il exhibe. S'il ne presente aucune version du protocole ou affiche une 
version du protocole differente de SOAP 1 . 1 , un nceud SOAP 1 . 1 se doit de le rejeter et eventuellement 
d'envoyerimmediatement un message d'eiTeur SOAP 1.1. (code d'erreur SOAP-ENV:VersionMismatch 
- la gestion des erreurs sera detaillee dans la section « La gestion des erreurs en SOAP 1 . 1 »). 

Lenveloppe peut contenir : 

• d'autres declarations d'espaces de noms ; 

• d'autres attributs, dont la presence est evidemment facultative, mais leur qualification par Fidentifiant 
d'un espace de noms est, en revanche, obligatoire ; 

• d'autres sous-elements dont la presence est facultative, mais leur qualification par Fidentifiant d'un 
espace de noms est obligatoire et leur position est situee obligatoirement apres I'element corps 
(voir figure 7-5). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Le profil de base 1.0 WS-I {draft) etablit que, pour cause d'interoperabilite, un nceud SOAP 1.1, s'il regoit un 
message dont I'element document (racine) presente Envel ope comme nom local mais un vocabulaire XML autre 
que http://schemas.xmlsoap.org/soap/envelope/, ne peut pas se limiter au rejet du message (comme il 
est etabli par la specification), mais doit generer un message d'erreur (R1015). Cette consigne semble un peu 
abusive car, par la structure meme du modele d'echange de base SOAP 1.1, on ne peut pas pretendre que tout 
nceud capable de traiter des messages SOAP 1 .1 soit en mesure de generer egalement des messages SOAP 1.1. 
Un message ne do/f pas contenir de descendants directs de SOAP-ENV:Envelope qui suivent SOAP- ENV: Body 
(R1 01 1 ). Pour cause d'interoperabilite, la structure de message SOAP 1.1 doit prevoir seulement deux descendants 
directs de I'element racine SOAP- ENV : Envel ope : I'element optionnel SOAP- ENV : Header et I'element obligatoire 
S0AP-ENV:Body. 



Evolutions SOAP 1.2 (draft) 

Le vocabulaire XML SOAP 1 .2 est bien sur different du vocabulaire XML SOAP 1 .1 . LURI du vocabulaire SOAP 1 .2 
est http://www.w3.org/2002/06/soap-envelope et le prefixe utilise par la specification est env. Le schema 
XML Schema pour la structure du message SOAP 1 .2 est localise a I'URL identifiant du vocabulaire SOAP 1 .2. 
SOAP 1 .2 introduit deux autres vocabulaires XML pour des elements et attributs qui sont utilises dans le cadre du 
traitement des erreurs : 

- http://www.w3.org/2002/06/soap-faults (prefixe utilise fit) pour des elements de I'en-tete qui detaillent 
certaines erreurs ; 

- http://www.w3.org/2002/06/soap-upgrade (prefixe utilise upg) pour des elements de I'en-tete lies au 
traitement des erreurs de version du protocole. 

SOAP 1.2 ne permet pas la presence d'autres elements apres le corps (la recommandation d'interoperabilite du 
profil de base 1 .0 R101 1 devient done une regie SOAP). 



L'en-tete 



Len-tete est un element optionnel. S'il est present dans un message SOAP 1.1, il doit etre un descendant 
direct de I'element enveloppe et place comme le premier de la sequence des descendants directs. 
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II peut contenir plusieurs elements descendants directs qui sont appeles entrees de l'en-tete. Toutes 
les balises des entrees de l'en-tete doivent etre des noms qualifies. 

L'en-tete fournit le mecanisme general et flexible qui permet d'ajouter des traits nouveaux et specialises 
a un message SOAP 1.1. Ces ajouts peuvent etre effectues dynamiquement, via l'ajout d'elements de 
l'en-tete, de facon decentralisee et modulaire, sans accord preventif des participants a la chaine 
d' ache mine me nt, au cours du cycle de transmission d'un message. Deux attributs reserves par la 
specification SOAP 1.1 (attributs d'en-tete) permettent d'indiquer : 

• le participant a la chaine d' acheminement qui est le consommateur designe de F element de F en-tete 
du message (attribut SOAP-ENV:actor) ; 

• si la consommation de F element est obligatoire ou facultative pour le consommateur designe (attribut 
SOAP-ENV:mustUnderstand). 

La specification SOAP 1.1 considere explicitement que les entrees de Fen-tete sont destinees a la mise 
en ceuvre de couches superieures et transversales de la technologie des services Web, comme la gestion 
des chaines d' acheminement, la gestion des transactions, la gestion de la securite, etc. 

La specification recommande Futilisation systematique des attributs SOAP-ENV: actor et SOAP- 
ENV:mustUnderstand. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Le nceud SOAP 1 .1 recepteur d'un message SOAP 1.1 doit traiter le message de fagon a faire apparaitre que la 
verification de tous les elements de l'en-tete qu'il doit obligatoirement traiter precede leur traitement (R1025). En 
pratique, il faut eviter d'effectuer un quelconque traitement du message si le traitement des elements de l'en-tete 
genere une erreur. Le suivi a la lettre de cette recommandation est absolument necessaire si le traitement du 
message genere chez le recepteur des changements d'etat et des effets de bord. 



Lattribut SOAP-ENV:actor 

Lattribut SOAP 1.1 SOAP-ENV: actor dans une entree de Fen-tete est utilise pour designer le consom- 
mateur de I'entreede l'en-tete. La valeur de F attribut S0AP-ENV:actor est un URL 



RecommandationsWS-l Basic Profile 1.0 (draft) 

La valeur de SOAP-ENV : actor est I'objet d'un accord prive entre I'emetteur et le recepteur de I'entree de l'en-tete 
qui contient I'attribut (R1026). 



LURI reserve par la specification SOAP 1.1 http://schemas.xmlsoap.org/soap/actor/next designe 
comme consommateur de I'entree de l'en-tete le premier nceud SOAP 1.1 suivant I'emetteur dans la 
chaine d' acheminement. 



Evolutions SOAP 1.2 {draft) 

SOAP 1.2 remplace I'attribut SOAP-ENV: actor par I'attribut env: role avec la meme semantique. 



La regie de designation du consommateur pour les entrees de l'en-tete d'un message SOAP 1.1 est 
finalement simple : 



Echanger avec un service - Format du message 

Chapitre 7 

• Le consommateur designe d'une entree de l'en-tete qui contient l'attribut SOAP-ENV:actor, ainsi 
que de tous ses sous-elements, est le nceud dont l'URI est la valeur de l'attribut. 

• Le consommateur designe d'une entree de l'en-tete qui contient l'attribut SOAP- ENV: actor ayant 
comme valeur l'URI http://schemas.xmlsoap.org/soap/actor/next est le premier nceud suivant 
l'emetteur du message dans la chaine d'acheminement. 

• Le consommateur designe d'une entree de l'en-tete qui ne contient pas d'attribut SOAP-ENV:actor, 
ainsi que de tous ses sous-elements, ne peut etre que le destinataire du message. 

La figure 7-6 presente une chaine d'acheminement avec un seul intermediaire: nice.guy.net veut 
envoyer un message a pretty.girl.net par 1' intermediaire de office.postalservice.com. 



nice.guy.net \— 1 . Message A M office.postalservice.com J- 2. Message A' 4 pretty.girl.net 



Figure 7-6 

Une chaine d'acheminement avec un seul intermediaire (I). 

La designation absolue du consommateur 

Voici le message A (figure 7-6) emis par nice.guy.net a 1' intention de office.postalservice.com : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Header> 

<pbs: postmark xml ns:pbs="http: //www. postal standards.org/basicservices/" 
SOAP- ENV :actor="http: //of fice.postalservice.com/"> 
<pbs:action>http: //www. postal standards. org/send</pbs:action> 
<pbs:sender> 

<pbs:senderURI>http: //nice. guy. net/</pbs:senderURI> 
</pbs:sender> 
<pbs:receiver> 

<pbs:receivertlRI>http: //pretty. girl .net/</pbs:receiverURI> 
<pbs: receiver PorOhttp: //pretty. girl . net/home. asp</pbs:receiverPort> 
</pbs:receiver> 
</pbs:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

<g: Greeting xmlns :g="http:/ /www. greetings.org/greetings/"> 

<g:text>Ciao !</g:text> 
</g:Greeting> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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Le message est bien recu par office.postalservice.com qui : 

1. parcourt Fen-tete du message ; 

2. identifie la valeurde SOAP-ENV:actor dans Fentree pbs:postmark comme sonpropre URI ; 

3. note que Faction demandee est Fenvoi simple du message (designee par FURI http://www 
.postalstandards.org/send) ; 

4. note la valeur de Felement pbs : recei verPort ; 

5. ignore Felement SOAP-ENV:Body ; 

6. construit un nouveau message dans lequel Fentree pbs:postmark est modifiee : Fattribut SOAP- 
ENV : actor et Felement pbs : acti on sont enleves, en outre, les elements pbs : sender et pbs : recei ver, 
son propre URI ainsi que la date et Fheure de reception du message (a Fheure de Greenwitch, 
selon le format ISO 8601) sont ajoutes ; 

7. envoie le nouveau message sur le port de reception http://pretty.girl .net /home. asp. 
Voici le message A' (figure 7-6) emis par office.postalservice.com a Fintention de pretty.girl.net: 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- E N V = " http://schemas.xml soap.org/soap/envel ope/" 

<SOAP-ENV:Header> 

<pbs: postmark xmlns :pbs="http: //www. postal standards.org/basicservices/"> 
<pbs:postmarker> 

<pbs:postmarkerURI> 

http://office.postalservice.com/ 
</pbs:postmarkerURI> 
</pbs:postmarker> 

<pbs:dateTime>2002-06-30T23:59:59</pbs:dateTime> 
<pbs: acti on>http: //www. postal standards. org/send</pbs: acti on> 
<pbs:sender> 

<pbs:senderURI>http: //nice. guy. net/</pbs:senderURI> 
</pbs:sender> 
<pbs:receiver> 

<pbs: recei verURI>http: //pretty. girl .net/</pbs: recei verLIRI> 
<pbs: recei ver Port>http: //pretty. girl . net/home. asp</pbs: recei ver Port> 
</pbs: recei ver> 
</pbs:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

A la reception, pretty.girl.net traite non seulement le corps du message, mais aussi les entrees d'en-tete. 
pretty.girl.net prend connaissance de Fidentifiant (URI) de Fexpediteur, mais aussi du fait que le petit 
mot recu est passe par office.postalservice.com, qui Fa horodate. 
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La designation relative du consommateur 

En effet, dans cette chaine d'acheminement, nice.guy.net n' a pas besoin de specifier « en dur » FURI de 
1' intermediate comme valeur de Fattribut SOAP-ENV:actor : l'URI special http://schemas.xmlsoap 
.org/soap/actor/next peut convenir. 



Evolutions SOAP 1.2 (draff) 

SOAP 1.2 garde la semantique de la valeur http://schemas.xmlsoap.org/soap/actor/next pour I'attribut 
SOAP- ENV: actor en SOAP 1.1 par le biais de la valeur http://www.w3.org/2002/06/soap-envelope/rol e 
/next pour I'attribut role. 

SOAP 1 .2 introduit deux nouvelles valeurs de rol e pour les nceuds SOAP 1 .2 : 

- http://www.w3.org/2002/06/soap-envelope/role/none : aucun nceud SOAP 1 .2 n'est autorise a traiter 
I'entree de I'en-tete ; 

- http://www.w3 . org/2002/06/soap-envel ope/ rol e/ul timateRecei ver : seul le destinataire est autorise 
a traiter I'entree de I'en-tete. 



Le message A (figure 7-6) produit et emis par nice.guy.net peut done etre le suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<S0AP-ENV:Envelope 

xmlns : SOAP -ENV=" http://schemas.xml soap. org/ soap/envelope/" 

<S0AP-ENV:Header> 

<pbs: postmark xmlns :pbs="http: //www. postal standards.org/basicservices/" 
SOAP- ENV :actor="http://schemas. xmlsoap.org/soap/actor/next"> 

</pbs:postmark> 

</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

L'avantage de cette approche est evident : le message « ne connait pas » le service Web qui Fachemine. 
Une fois le message prepare, nice.guy.net peut decider a la derniere minute du fournisseur de services 
postaux Web qu'il va sollicker pour envoyer son petit mot a pretty.girl.net, sur la base de differents 
criteres comme le prix, la qualite de service, etc. 

II est clair que, pour obtenir ce resultat, il faut qu'un certain nombre de fournisseurs de services 
postaux Web se soient mis d' accord sur le format et sur un traitement des entrees des en-tetes dont le 
vocabulaire XML est : http://www.postalstandards.org/basicservices/. 

LattributSOAP-ENV:mustUnderstand 

Lattribut SOAP 1.1 SOAP-ENV:mustUnderstand est utilise pour indiquer que la consommation de 
I'entree de I'en-tete par le consommateur potentiel designe est obligatoire (valeur "1") ou facultative 
(valeur "0", valeur par defaut). 
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RecommandationsWS-l Basic Profile 1.0 (draft) 

En fait, la valeurde SOAP-ENV:mustUnderstand est traitee comme etant de type xs: boolean (xs est leprefixe 
pour XML Schema Datatype) et done son espace lexical est constitue de 0, 1, false, true (R1013). 



Evolutions SOAP 1.2 (draft) 

En SOAP 1.2, 1'attributmustunderstand persiste et prend « officiellement » le type xs: boolean. 



La ligne de conduite a tenir par les nceuds participant a une chaine d'acheminement d'un message 
SOAP 1.1 est la suivante : 

• Le consommateur designe d'un element de l'en-tete avec SOAP-ENV:mustUnderstand="l" doit 
consommer l'element en question. S'il en est « incapable » (le sens de cette « incapacite » sera 
precise dans la section consacree a la gestion des eiTeurs), il doit rejeter le message. 

• Le consommateur designe d'un element de l'en-tete avec SOAP-ENV:mustUnderstand="l", qui est 
« incapable » de consommer le message, doit non seulement le rejeter mais peut decider d'envoyer 
un message d'erreur a l'emetteur du message qu'il vient de recevoir. Ce traitement ne peut etre 
applicable que si le recepteur est capable d'emettre des messages SOAP 1.1. 

• Le consommateur designe de l'entree de l'en-tete avec SOAP-ENV:mustUnderstand="0" peut 
consommer ou non cette entree. S'il decide de ne pas la consommer, il doit reemettre le message 
tel quel vers le prochain nceud de la chaine d'acheminement (meme si la valeur de SOAP-ENV : actor 
le designe directement, done comme consommateur exclusif). Dans ce cas, l'element en question 
ne sera consomme par aucun nceud intermediate et echouera chez le destinataire, qui, en theorie, 
n'a pas le droit de le consommer non plus. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Le profil de base 1.0 WS-I {draft) etablit que, pour cause d'interoperabilite, un nceud SOAP 1.1, s'il regoit un 
message avec une entree de l'en-tete qu'il doit traiter (SOAP-ENV:mustUnderstand="l") et qu'il ne sait pas 
traiter, ne peut pas se limiter au rejet du message (comme il est etabli par la specification), mais doit generer un 
message d'erreur avec code SOAP-ENV:MustUnderstand (R1 027). Cette consignesembleun peu abusive car, 
par la structure meme du modele d'echange SOAP 1.1, on ne peut pas pretendre que tout nceud capable de 
consommer des messages SOAP 1.1 soit aussi en mesure d'en produire ou, a I'inverse, que tout nceud capable 
de produire des messages SOAP soit aussi capable d'en consommer. 



Nous allons supposer, par exemple, que nice.guy.net veut envoyer toujours le meme petit mot a 
pretty.girl.net, mais qu'il souhaite un service d'envoi recommande (fiabilise). II souhaite en fait que le 
service postal Web utilise un protocole de transport fiabilise (voir chapitre 18) pour transmettre son 
message au destinataire. Si le service postal Web n' arrive pas pour une raison quelconque a faire 
parvenir le message au destinataire, il doit en informer l'expediteur. L'envoi recommande est un 
service normalise par www.postalstandards.org (dont le vocabulaire XML est identifie par http://www 
. postal standards . org/smartservi ces/, relatif a la nouvelle version de services postaux) offert, entre autres, 
par office.smartpservice.com. Par ailleurs, nice.guy.net souhaite que le service soit accompli par office 
.smartpservice.com. 
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Figure 7-7 

Une chaine d'acheminement avec un seul intermediaire (II). 

Voici le message A dans ce nouveau contexte (figure 7-7, qui se distingue de la figure 7-6 seulement 
par le nom de l'intermediaire) : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap. org/ soap/envelope/" 

<SOAP-ENV:Header> 

<pss: postmark xml ns:pss="http: //www. postal standards.org/smartservices/" 
SOAP-ENV : actor="http : //of f i ce . smartpservi ce . com/" 
SOAP-ENV:mustUnderstand="l"> 

<pss:action>http: //www. postal standards. org/reliableSend</pss:action> 
<pss : i d>http: //ni ce . guy . net/1 etter#00O00K/pss : i d> 
<pss:sender> 

<pss:senderURI>http: //nice. guy. net/</pss:senderURI> 
<pss :senderPort>http: //nice. guy. net/home. jsp</pss:senderPort> 
</pss:sender> 
<pss:receiver> 

<pss:receiverURI>http: //pretty. girl .net/</pss:receiverURI> 
<pss: receiver Port>http: //pretty. girl . net/home. asp</pss:receiverPort> 
</pss:receiver> 
</pss:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Nous notons immediatement que, pour obtenir un tel service, nice.guy.net doit marquer le message 
avec un identifiant unique a rappeler en cas de problemes. II utilise pour cela l'URI http://nice 
.guy. net/1 etter#000001 comme valeur de l'element pss: id. 

office.smartpservice.com est effectivement capable d' assurer le service et done : 

1. parcourt l'en-tete du message ; 

2. identifie la valeur de SOAP-ENV: actor dans l'entree pss: postmark comme sonpropre URI ; 

3. note que Faction demandee est l'envoi recommande du message (designee par l'URI http : //www 
.postal standards.org/rel iabl eSend) ; 

4. note 1' identifiant du message, valeur de l'element pss : i d ; 
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5. note la valeurde Felement pss:receiverPort ; 

6. ignore Felement SOAP- ENV: Body ; 

7. constmit un nouveau message dans lequel F entree pss: postmark est modiflee : les attributs SOAP- 
ENV:actor et SOAP-ENV:mustUnderstand, ainsi que Felement pss:action et pss:senderPort sont 
supprimes. En revanche, les elements pss: sender et pss: receiver, son propre URI ainsi que la 
date et Fheure de reception du message sont ajoutes ; 

8. envoie le nouveau message sur le port de reception http : //pretty . gi rl .net/home . asp en utilisant 
son protocole fiabilise. 

Le message A' (figure 7-7), transmis par office.smartpservice.com a pretty.girl.net, vehicule par son protocole 
fiabilise, est done le suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- ENV=" http://schemas.xml soap.org/soap/envel ope/" 

<SOAP-ENV:Header> 

<pss: postmark xmlns :pss="http: //www. postal standards.org/smartservices/"> 
<pss:postmarker> 

<pss:postmarkerURI> 

http : //of f i ce . smartpservi ce . com/ 
</pss:postmarkerURI> 
</pss:postmarker> 

<pss:dateTime>2002-06-30T23:59:59</pss:dateTime> 
<pss:action>http: //www. postal standards.org/rel iableSend</pss:action> 
<pss:sender> 

<pss:senderURI>http: //nice. guy. net/</pss:senderURI> 
</pss:sender> 
<pss:receiver> 

<pss:receiverURI>http: //pretty. girl .net/</pss:receiverURI> 
<pss: receiver Port>http: //pretty. girl . net/home. asp</pss: receiver Port> 
</pss:receiver> 
</pss:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Nous allons supposer que, si office.smartpservice.com est bien en mesure d'assurer le service d'envoi 
recommande, office.postalservice.com n'a pas encore mis en ceuvre les nouveaux services d'echange 
fiable (http://www.postalstandards.org/smartservices/), specifies par Forganisation interprofession- 
nelle a laquelle il adhere avec office.smartpservice.com. Si un message comme le precedent lui etait 
envoye par nice.guy.net, la specification SOAP 1.1 Fobligerait a rejeter le message et, eventuellement, 
a retourner un message d'erreur a Fexpediteur. 

II se trouve qu' office.postalservice.com est en relation de partenariat avec office.smartpservice.com, qui 
assure le service d'envoi recommande. En effet, office.postalservice.com reachemine les messages a son 
partenaire en cas de requete d'envoi recommande. 
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Une chaine d'acheminement plus tolerante peut etre mise en ceuvre selon le schema de la figure 7-8. 



office.smartpservice.com 

r 



2. Message A' 



nice.guy.net | - 1 . Message A ►[ office.postalservice.com 




3. Message A" 



pretty.girl.net 



Figure 7-8 

Chaine d'acheminement avec detour. 

Pour mettre en ceuvre cette chaine d'acheminement, il faut operer deux changements : 

• faire sauter la contrainte SOAP-ENV:mustUnderstand="l" : il suffit pour cela d'enlever l'attribut 
SOAP-ENV:mustUnderstand ; 

• remplacer comme valeur de SOAP-ENV:actor FURI http://office.smartpservice.com/ par l'URI 
generique http://schemas.xmlsoap.org/soap/actor/next. 

Voici done le message emis par nice.guy.net a Fintention de office.postalservice.com : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap. org/ soap/envelope/" 

<SOAP-ENV:Header> 

<pss: postmark xml ns:pss="http: //www. postal standards.org/smartservices/" 
SOAP-ENV:actor=" http://schetnas.xmlsoap. org/soap/actor/nexf > 
<pss:action>http: //www. postal standards. org/reliableSend</pss:action> 
<pss:id>http: //nice. guy. net/1 etter#00O00K/pss:id> 
<pss:sender> 

<pss:senderURI>http: //nice. guy. net/</pss:senderURI> 
<pss :senderPort>http: //nice. guy. net/home. jsp</pss:senderPort> 
</pss:sender> 
<pss:receiver> 

<pss:receiverURI>http: //pretty. girl .net/</pss:receiverURI> 
<pss: receiver Port>http: //pretty. girl . net/home. asp</pss:receiverPort> 
</pss:receiver> 
</pss:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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office.postalservice.com recoit done ce message envoye par nice.guy.net. office.postalservice.com est destinataire 
de F entree d'en-tete pss: postmark, mais il se rend compte qu'il n'est pas capable de traiter cette 
entree de l'en-tete qui lui est destinee. Au lieu de rejeter le message et de retourner un message 
d'erreur a l'expediteur (il serait force d'agir ainsi avec SOAP-ENV:mustUnderstand="l" dans 1' entree de 
l'en-tete), cette fois-ci, il envoie exactement le meme message a office.smartpservice.com qui se 
comporte done exactement comme nous Favons decrit precedemment. 



Le corps 



Le corps d'un message SOAP 1 . 1 est produit par l'expediteur du message et consomme obligatoirement 
par le destinataire, independamment du nombre de noeuds intermediaries qui sont susceptibles 
d'acheminer le message. II en est de meme des elements facultatifs et « proprietaires » qui suivent le 
corps. 

L'element corps est obligatoirement present dans un message SOAP 1.1 comme descendant direct de 
l'element enveloppe, suivant immediatement l'element en-tete (si present) et suivi eventuellement 
par les elements proprietaires. 

L'element corps peut contenir un ensemble d'elements descendants, qui peuvent etre qualifies par la 
reference a un ou plusieurs espaces de noms. Ces elements sont appeles entrees du corps. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Pour cause d'interoperabilite, les descendants directs de l'element S0AP-ENV:Body doivent exhiber des noms 
qualifies car I'interpretation de noms non qualifies est ambigue (R1014). 



L'element corps peut egalement contenir un element SOAP 1 . 1 erreur (SOAP- ENV : Faul t), qui est defini 
par la specification, pour traiter les cas d'erreur. 

La specification SOAP 1 . 1 suggere de considerer le corps comme semantiquement equivalent a une 
entree de l'en-tete sans attribut S0AP-ENV:actor (et done destinee a la consommation du destinataire) 
et avec l'attribut SOAP-ENV:mustUnderstand="l". Cela veut dire, entre autres, que si le destinataire 
n'est pas en mesure de consommer le coips, il doit rejeter le message et, s'il en a la possibilite, il doit 
retourner un message d'erreur a l'emetteur. 

La gestion des erreurs en SOAP 1 .1 

L'erreur SOAP 1.1 se produit toujours a cause d'une incapacite du nceud recepteur du message 
SOAP 1.1 a consommer le message ou la partie du message qui lui est destine. Cette incapacite peut 
etre due : 

• soit a un defaut syntaxique ou semantique du message ; 

• soit a une defaillance du nceud recepteur lors du traitement du message. 

Le message recu implique dans une situation d'erreur sera appele message en erreur (faulty 
message). Un message en erreur est done soit un message syntaxiquement ou semantiquement incor- 
rect, soit un message correct dont le traitement a echoue a cause d'une defaillance du nceud recepteur. 
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II est important de souligner que, lorsque Ton se trouve en presence d'une situation d'erreur SOAP 1.1, le niveau 
transport a fonctionne, au moins partiellement : 

- la connexion a pu etre etablie ; 

- la transmission a ete effectuee et le message en erreur a ete regu. 

Les erreurs de transport ne sont done pas des erreurs SOAP : elles sont par consequent traitees au niveau du 
protocole de transport, meme si Ton ne peut pas exclure totalement la propagation de I'erreur de transport, a savoir 
une corruption sournoise du message SOAP 1 .1 lui-meme. 



La specification SOAP 1.1 evoque les circonstances dans lesquelles le recepteur d'un message 
SOAP 1.1 reconnait une situation d'erreur associee au message recu (message en erreur), ainsi que 
les circonstances dans lesquelles le recepteur d'un message en erreur signale une situation d'erreur. 
Ce signalement peut prendre la forme de la transmission d'un message d'erreur {fault message) a 
l'intention de l'emetteur de depart. Le message d'erreur contient toujours des informations sur la 
nature de I'erreur a l'intention de l'emetteur du message en erreur. La specification SOAP precise le 
format et le contenu du message d'erreur. 

La gestion des erreurs SOAP 1.1 comprend done trois etapes distinctes : 

1. le traitement du message en erreur par son recepteur ; 

2. le signalement de I'erreur et la production et remission du message d'erreur correle au message 
en erreur ; 

3. la reception du message d'erreur de la pail de l'emetteur du message en erreur. 

Le traitement du message en erreur 

L'incapacite de la pail du recepteur a consommer le message en erreur (les parties qui lui sont destinees 
pour consommation) doit se traduire, dans des cas repertories (voir la description des types d' erreurs 
SOAP 1.1 dans la section « Les types d' erreurs »), par le rejet du message de la part du recepteur ou 
par l'echec de son traitement. 

Cependant, la specification SOAP 1 . 1 ne precise pas la semantique operationnelle du rejet du message 
ou de l'echec du traitement. L'emetteur du message en erreur n'est pas autorise a tirer des conclusions 
certaines sur le traitement total ou partiel du message en erreur et sur ses consequences. II est done 
possible que des changements d'etat et/ou des effets de bord se soient produits suite au traitement du 
message en erreur par le recepteur. 



Recommandations WS-I Basic Profile 1.0 (draft) 

Lorsqu'une situation d'erreur est detectee, suite a un message en erreur recu par un nceud SOAP 1 .1 , les exigen- 
ces d'interoperabilite precisent que le traitement du message en erreur de la part de ce nceud ne doit pas aller au- 
dela des operations strictement necessaires au signalement de I'erreur (via un message d'erreur, la levee d'une 
exception, I'affichage d'une fenetre sur une console) (R1028). 
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La situation ideale serait que : 

1. Le recepteur du message en erreur complete F analyse syntaxique et semantique du message en 
erreur avant de declencher tout traitement produisant les changements d'etat et les effets de bord 
consequences de la consommation du message. 

2. Le recepteur mette en ceuvre une gestion transactionnelle des traitements produisant les 
changements d'etat et les effets de bord consequences de la consommation du message. La gestion 
transactionnelle permet de traiter correctement les cas de defaillance (panne franche) du recepteur. 

Le signalement de I'erreur 

Le recepteur doit signaler la situation d' erreur consequente a la reception d'un message en erreur par 
tous les moyens a sa disposition (levee d'une exception, affichage sur une console utilisateur ou 
administrateur, production d'un journal de bord, etc.). 



Recommandations WS-I Basic Profile 1 .0 {draft) 

Lorsqu'un noeud SOAP 1.1 genere un message d'erreur, il doit, si possible, notifier un utilisateur (acteur humain) 
de remission de ce message par tout moyen approprie (R1030). 



Lemission d'un message d'erreur a l'intention de l'emetteur du message en erreur est un de ces 
moyens. La specification SOAP 1.1 definit les modalites de ce moyen de signalement et laisse a 
1' implementation des nceuds SOAP les autres modalites. 

Les capacites d'emission et de reception des messages SOAP 1.1 

Le recepteur peut etre incapable d'emettre des messages SOAP 1.1 (c'est un pur recepteur UDP, par 
exemple) ou peut etre capable d'emettre des messages SOAP 1.1 seulement dans des circonstances 
particulieres (c'est un serveur sur un protocole de transport bidirectionnel comme HTTP, capable de 
recevoir des requetes et d'emettre des reponses correlees : dans ce cas, il peut utiliser la reponse pour 
vehiculer le message d'erreur). 

Le point determinant est par consequent la capacite d'emission de messages SOAP 1.1, et done de 
messages d'erreur, de la part du recepteur du message en erreur. Nous pouvons distinguer quatre 
classes de base pour les nceuds SOAP 1.1, par rapport a leurs capacites d' emission/reception de 
messages SOAP 1.1 : 

• Emetteur SOAP 1.1 est un noeud qui a une capacite d'emission de messages a sens unique SOAP 1.1. 

• Recepteur SOAP 7. 7 est un noeud qui a une capacite de reception de messages a sens unique SOAP 1.1. 

• Client SOAP 1.1 est un noeud qui a une capacite d'emission de requetes SOAP 1.1 et de reception 
de reponses SOAP 1.1 correlees aux requetes emises. 
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• Serveur SOAP 1.1 est un nceud qui a une capacite de reception de requetes SOAP 1 . 1 et d'emission 
de reponses SOAP 1 . 1 correlees a la requete recue. 

Les capacites d' emission/reception d'un nceud SOAP 1.1 resultent de la combinaison de ces classes 
de base. 



La correlation entre message en erreur et message d'erreur 

La correlation entre message en erreur et message d'erreur est un element essentiel du mecanisme de 
gestion des erreurs SOAP : un message d'erreur est un outil informationnel et ne remplit son role que 
s'il est correle de facon non ambigue au message en erreur qui l'a provoque. 

Par ailleurs, la correlation directe et implicite entre un message en erreur et un message d'erreur n'est 
possible qu'entre un client et un serveur SOAP 1.1, dans le style d'echange requete/reponse, lorsque 
le message en erreur est la requete SOAP. Dans ce cas, le message d'erreur remplace la reponse au 
message (requete) en erreur et la correlation est assuree par le style d'echange. 



Recommandations WS-I Basic Profile 1.0 (draft) 

Lorsqu'une consequence escomptee du traitement d'un message SOAP 1 .1 de la part d'un nceud SOAP 1 .1 est la 
generation d'un message SOAP 1.1 en reponse au premier message (style requete/reponse), et que le message 
recu est en erreur, alors le noeud doit transmettre le message d'erreur a la place de la reponse (R1029). 



En dehors de ce cas precis, la correlation message en erreur et message d'erreur, comme celle entre 
les messages dans une « conversation », ne peut etre obtenue que par un protocole applicatif permettant 
de doter chaque message d'un identifiant unique. Cet identifiant est rappele explicitement chaque fois 
qu'il faut etablir une correlation avec un autre message. 

Par ailleurs, meme si dans la specification, remission d'un message d'erreur semble toujours liee au 
constat prealable d'une erreur, elle n'exclut pas d'emettre un message d'erreur independamment 
d'une situation d'erreur, pour signaler un etat (notification de status). 

La notification de status sert a signaler une situation courante (status) de defaillance d'un nceud, sur 
initiative du nceud lui-meme. On pourrait imaginer, par exemple, qu' office.postalservice.com envoie a 
ses clients, a son initiative, un message d'erreur sur l'indisponibilite temporaire de ses services et, 
ensuite, sur le retablissement du fonctionnement normal. 

Le tableau 7-1 resume les attitudes des nceuds par rapport a la reception et au traitement d'un message 
en erreur et a F envoi d'un message. 
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Tableau 7-1. Resume des capacites demission/reception 
d'un message d'erreur par les nceuds SOAP 1.1 
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precedent) 









L'element erreur (SOAP-ENV .fault) 

L'element erreur (SOAP-ENV:Fault) du corps d'un message SOAP 1.1 est destine a vehiculer une 
information d'erreur ou d'etat. 

La specification SOAP 1.1 precise que l'element erreur est obligatoirement une entree du corps. 
Cette entree peut etre presente au plus une fois dans le corps d'un message SOAP 1.1. Elle peut etre 
la seule entree ou etre accompagnee d'autres entrees du corps. 

La specification SOAP 1.1 definit quatre sous-elements de F entree erreur (SOAP- ENV: Fault) : 

• l'element code d'erreur (f aul tcode) ; 

• l'element liberie d'erreur (f aul tstring) ; 

• l'element expediteur du message d'erreur (f aul tactor) ; 

• l'element detail d'erreur (detai 1 ). 

La specification SOAP 1.1 n'exclut pas la presence d' elements applicatifs dont les noms appartien- 
nent a des vocabulaires XML applicatifs comme descendants directs de SOAP- ENV: Fault. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Pour cause d'interoperabilite, l'element SOAP- ENV : Faul t ne doit pas presenter de descendants directs autres que 
les elements specifies par SOAP 1.1, a savoir faul tcode, faul tstring, faultactoret detail (R1000). 
En outre, les noms des descendants directs SOAP 1.1 de SOAP-ENV: Fault doivent etre des noms non qualifies 
(sans prefixe) : faultcode, faultstring, faultactor et detail (R1001). 
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Lelement code d'erreur (faultcode) 

L' element code d'erreur (f aul tcode) vehicule une information sur 1' erreur rencontree qui est typiquement 
destinee a Fexploitation par programme. L' element f aul tcode est obligatoirement present dans F element 
SOAP-ENV : Faul t et sa valeur doit etre un nom qualifie. 

SOAP 1.1 definit quatre types d'erreurs, chacun designe par un « code », sous le format d'un nom 
qualifie par le vocabulaire XML http://schemas.xnilsoap.org/soap/envelope/. 

Les codes d'erreurs SOAP 1.1 sont : 

• SOAP-ENV:VersionMismatch : le code signale que le vocabulaire XML des balises de structure 
(Envelope, Header, Body, Faul t) du message en erreurn'est pas celui de SOAP 1.1 (http://schemas 
.xmlsoap.org/soap/envelope/) ; 

• SOAP-ENV:MustUnderstand : le code signale que l'emetteur du message d'erreur a recu comme 
message en erreur un message qu'il est oblige de traiter (SOAP-ENV:mustUnderstand="l") et qu'il 
n'est pas fonctionnellement capable de traiter ; 

• SOAP- ENV : CI i ent : le code signale que le message en erreur est syntaxiquement et/ou semantiquement 
incorrect : soit il est mal forme, soit il ne contient pas l'information appropriee pour etre convena- 
blement traite ; 

• SOAP-ENV:Server : le message en erreur n'a pas pu etre traite a cause d'une defaillance technique 
ou applicative du nceud recepteur : ce dernier code peut egalement etre utilise pour des notifications 
de status. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Pour cause d'interoperabilite, la valeur de faultcode do/fetre obligatoirement une des quatre valeurs SOAP 1.1. 
Ni les codes d'erreurs personnalises (exemple : myCode:ProcessingError, ou myCode designe un vocabulaire 
XML de codes d'erreur applicatifs), ni les codes specialises (exemple presente plus haut : SOAP- ENV: Client 
.Authentication) ne sont admis comme valeurs de faultcode (R1004). 



Les codes d'erreurs SOAP 1.1 peuvent etre, selon la specification, specialises par un suffixe (separe 
par un point), par exemple : SOAP- ENV: Client. Authentication. 

Le code d'erreur ci-dessus indique que l'erreur est une erreur SOAP 1.1, de la classe CI i ent, avec une 
specialite Authenti cati on. Le sens de ce code, issu d'un accord prive entre les interlocuteurs, est que 
l'erreur vient d'un probleme d'authentification du nceud emetteur du message en erreur. 



Evolutions SOAP 1.2 (draft) 

SOAP 1.2 utilise comme nom d'element env: Code a la place de faultcode. 

L'element env : Code presente une structure arborescente, avec deux sous-elements : env : Node et env : Rol e. 

SOAP 1 .2 abolit la notation point.ee pour les codes d'erreurs. Les codes d'erreurs gardent le format env : name, ou 

env est le qualificatif du vocabulaire XML SOAP 1.2 http://www.w3.org/2002/06/soap-envelope et name 

est la classe d'erreur. 

SOAP 1 .2 remplace les codes d'erreurs SOAP-ENV : CI i ent et SOAP-ENV : Server respectivement par env : Sender 

et env: Receiver. 

SOAP 1 .2 introduit un nouveau code d'erreur : env : DataEncodi ngUn known (en relation avec I'incapacite a decoder le 

contenu du message). 
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L'element libelle d'erreur (faultstring) 

L'element libelle d'erreur (faul tstri ng) est typiquement destine a fournir une explication de l'erreur 
comprehensible par les acteurs humains (generalement, les concepteurs et les administrateurs des 
services Web). II est obligatoirement present dans l'element SOAP-ENV : Faul t. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

L'element faul tstri ng peut contenir un attribut xml : 1 ang, sans problemes d'interoperabilite (R1016). 



Evolutions SOAP 1.2 (draft) 

SOAP 1.2 utilise comme nomd'element env: Reason a la place de faultstring. 



L'element expediteur du message d'erreur (faultactor) 

L'element expediteur du message d'erreur (faultactor) est destine a fournir des informations sur le 
nceud expediteur du message d'erreur. Sa valeur est un URI. 

La presence d'un tel element est obligatoire si l'expediteur du message d'erreur est un nceud interme- 
diaire dans la chaine d'acheminement du message. Si un tel element est absent, cela veut dire que 
l'expediteur du message d'erreur est le destinataire du message en erreur. 

L'element detail d'erreur (detail) 

L'element detail de l'erreur (detail ) est destine a fournir de l'information d'origine applicative sur 
l'erreur survenue. Si l'erreur est survenue lors du traitement du corps du message en erreur, l'element 
detail est obligatoirement present dans le message d'erreur. En revanche, l'absence de cet element 
indique que l'erreur n'est pas survenue lors du traitement du corps du message en erreur. 

Par ailleurs, detail ne doit pas etre utilise pour vehiculer de l'information sur les erreurs survenues 
lors du traitement des entrees de l'en-tete. 

L'element detai 1 peut contenir des sous-elements appeles entrees du detail. Chaque entree du detail 
est independante des autres, possede un nom qualifie, et l'attribut SOAP 1.1 SOAP-ENV:encodingStyl e 
peut etre utilise pour indiquer le style de codage des entrees du detail (voir le chapitre 8). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

L'element detail peut avoir comme descendants des elements dont les noms appartiennent a n'importe quel 

vocabulaire XML applicatif. II peut avoir notamment comme descendants des elements aux noms qualifies 

(R1002). 

Pour cause d'interoperabilite, l'element detai 1 peut contenir tout attribut qualifie sauf ceux dont le vocabulaire est 

http://schemas.xmlsoap.org/soap/envelope/ (R1003) : par exemple la declaration de style de codage 

SOAP-ENV :encodingStyle n'est pas admise (les limitations a I'usage de cet attribut seront detaillees dans le 

prochain chapitre). 
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Les types d'erreurs 

Nous allons illustrer l'usage des codes d'erreurs par un exemple dans lequel le message en erreur se 
presente a un intermediate dans la chaine d'acheminement (voir figure 7-9). En effet, le destinataire 
du message en erreur A est, dans tous les cas d'erreurs traites, pretty.girl.net. Cela nous permet de donner 
plus de generalite et de completude a l'exemple. II faut noter que l'usage de l'element f aultactor est 
obligatoire dans une telle situation car l'expediteur du message d' erreur n'est pas le destinataire du 
message en erreur. 



1 . Message A 
(message en erreur) 



nice.guy.net 



X 



\ 



office.postalservice.com 



pretty.girl.net 



2. Message B 
(message d'erreur) 



Figure 7-9 

La chaine interrompue par une erreur (I). 



Le code SOAP-ENV:VersionMismatch 

La valeur SOAP-ENV:VersionMismatch de faultcode indique que le vocabulaire XML des balises de 
structure du message en erreur n'est pas http://schernas.xmlsoap.org/soap/envelope/. En SOAP 1.1, 
le vocabulaire http://schemas.xmlsoap.org/soap/envelope/ est le seul acceptable pour les balises de 
structure (Envelope, Header, Body, Fault) et indique que le message est conforme a la specification 
SOAP 1.1. 

Dans l'exemple presente figure 7-9, nice.guy.net envoie a office.postalservice.com le message A suivant, 
ayant comme destinataire pretty.girl.net: 

<?xml version="1.0" encoding="UTF-8"?> 
<S0AP10:Envelope 

xmlns:S0AP10="urn:schemas-xmlsoap-org:soap.vl"> 

<S0AP10:Header> 

</S0AP10:Header> 
<S0AP10:Body> 

</S0AP10:Body> 
</S0AP10:Envelope> 

Le vocabulaire XML pour les noms des balises de structure est celui associe a la specification 
SOAP 1.0. office.postalservice.com est un nceud SOAP 1.1, et reagit done par le rejet du message A (et 
done le refus de l'acheminer vers pretty.girl.net) et l'envoi a nice. guy. net du message d'erreur B (voir 
figure 7-9) suivant : 



Technologies des services Web 

Deuxieme Partie 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- ENV="http://schemas. xmlsoap.org/soap/envelope/"> 
<SOAP-ENV:Body> 
<SOAP-ENV:Fault> 

<faultcode>SOAP-ENV:VersionMismatch</faultcode> 
<faultstring>Soap 1.0 is not supported. </faultstring> 
<faultactor>http: //off ice. postal service. com/</faultactor> 
</SOAP-ENV:Fault> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Le code SOAP-ENV:MustUnderstand 

Le code SOAP- ENV :MustUnderstand de faultcode indique que Femetteur du message d'eireur a recu 
comme message en erreur un message contenant un element : 

• dont il est designe consommateur (la valeur explicite ou par defaut de SOAP- ENV : actor le designe) ; 

• qu'il a l'obligation de traiter (SOAP-ENV:mustUnderstand="l") ; 

• et qu'il n'est pas fonctionnellement capable de traiter (il ne « comprend » pas) F element en question. 
Nous rappelons que si cet element est : 

• une entree de Fen-tete, le consommateur designe est soit un nceud dans la chaine d'acheminement 
explicitement designe par SOAP-ENV:actor, soit, a defaut de SOAP-ENV:actor, le destinataire ; 

• le corps (ou un de ses descendants), le consommateur designe est le destinataire, avec obligation 
de toujours « comprendre » F element (ce qui est equivalent, pour les entrees de Fen-tete, a SOAP- 
EN V: must Under standi "1"). 

Considerons Fexemple, toujours illustre par la figure 7-9, dans lequel nice.guy.net envoie le message A 
suivant a office.postalservice.com (le destinataire est toujours pretty.girl.net) : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- E N V = " http://schemas.xml soap.org/soap/envel ope/" 

<SOAP-ENV:Header> 

<pss : postmark xml ns : pss=" http://www.postalstandards.org/smartservices/" 
SOAP- ENV :actor="http: //off ice. postal service. com/" 
SOAP- ENV :mustUnderstand="l"> 
<pss:action>http: //www. postal standards.org/rel iableSend</pss:action> 

</pss:postmark> 

</SOAP-ENV:Header> 

<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Dans ce message, nice.guy.net demande a office.postalservice.com de traiter imperativement Fen-tete 
pss:postmark, qualifie par le vocabulaire XML http://www.postalstandards.org/smartservices/, 
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qui designe des prestations de services postaux Web qu'il ne sait pas pourvoir (notamment F envoi 
recommande). 

office.postalservice.com rejette le message A (il ne Fachemine pas a pretty.girl.net) et envoie a nice.guy.netle 
message d'erreur B (voir figure 7-9) suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Body> 
<SOAP-ENV:Fault> 

<f aul tcode>SOAP-ENV : MustUnderstand</f aul tcode> 
<faultstring>Misunderstood header entry</faultstring> 
<f aul tactor>http: //off ice. postal service. com/</f aul tactor> 
</SOAP-ENV:Fault> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



Evolutions SOAP 1.2 (draft) 

SOAP 1.2 definit une nouvelle entree de I'en-tete Misunderstood pour vehiculer des informations dans le 
message d'erreur de code SOAP-ENV:MustUnderstand, genere suite a I'incapacite de traiter une entree de I'en-tete 
du message en erreuravec SOAP-ENV:mustUnderstand="l". 



Le code SOAP-ENV:Client 

Lecode SOAP- ENV : Client de fault code indique que soit le message en erreur est mal forme, soitilne 
contient pas Finformation appropriee pour etre convenablement traite (erreur syntaxique ou semantique). 

Dans Fexemple suivant, nice. guy. net envoie a office.postalservice.com le message A (voir figure 7-9), pour 
qu'il soit achemine a pretty.girl.net: 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns : SOAP -ENV=" http://schemas.xml soap.org/soap/envel ope/" 

<SOAP-ENV:Header> 

<pbs: postmark xml ns:pbs="http: //www. postal standards.org/basicservices/" 
SOAP- ENV :actor="http: //of fice.postalservice.com/"> 
<pbs:action>http: //www. postal standards. org/send</pbs:action> 
<pbs:sender> 

<pbs:senderURI>http: //nice. guy. net/</pbs:senderURI> 
</pbs:sender> 
</pbs:postmark> 
</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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office.postalservice.com ne peut pas pourvoir la prestation http : //www .postal standa rds . org/send car les 
coordonnees du destinataire : 
<pbs:receiver> 

<pbs:receiverURI>http: //pretty. girl .net/</pbs:receiverURI> 
<pbs: receiver Port>http: //pretty. girl . net/home. asp</pbs: receiver Port> 
</pbs:receiver> 

ne sont pas specifiers dans le message. II rejette done le message A et envoie a nice.guy.net le message 
d'erreur B (voir figure 7-9) : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- E N V = " http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Body> 
<SOAP-ENV:Fault> 

<faultcode>SOAP-ENV:Client</faultcode> 
<faultstring>Missing routing data</faultstring> 
<faultactor>http: //off ice. postal service. com/</faultactor> 
<detail xmlns :d="http: //of fice.postalservice.com/details"> 

<d:reason>Missing last receiver's name and address</d:reason> 
</detail> 
</SOAP-ENV:Fault> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Le code SOAP-ENV:Server 

Le code SOAP-ENV:Server de faultcode indique que le message en erreur n'a pas pu etre traite a cause 
d'une defaillance technique ou applicative du nceud recepteur. La defaillance peut survenir a 
n'importe quel moment du traitement : si le recepteur estime qu'il est pertinent de correler la 
defaillance avec la reception du message en erreur il repond avec un message d'erreur. 



1 . Message A 
(message en erreur) 



\ 



X 



nice.guy.net ( office.smartpservice.com J pretty.girl.net 






2. Message B 
(message d'erreur) 



Figure 7-10 

La chaine interrompue par une erreur (II). 

Nous allons reconsiderer l'exemple de nice.guy.net qui demande un envoi recommande, par Fintermediaire 
de office.smartpservice.com, a pretty.girl.net (figure 7-10, laquelle se distingue de la figure 7-9 seulement 
par FURI de l'intermediaire). 
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nice. guy. net trans met le message A (figure 7-10) suivant a office.smartpservice.com avec une requete 
d' envoi recommande du message a pretty.girl.net: 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns : SOAP -ENV=" http://schemas.xml soap.org/soap/envel ope/" 

<SOAP-ENV:Header> 

<pss: postmark xmlns :pss="http: //www. postal standards.org/smartservices/" 
SOAP- ENV:actor="http://schemas. xmlsoap.org/soap/actor/next"> 
<pss:action>http: //www. postal standards. org/reliableSend</pss:action> 

</pss:postmark> 

</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Le service d'envoi recommande d' office.smartpservice.com est bati sur une architecture de files persistantes 
de messages. Le serveur qui doit effectuer le transfert du message vers pretty.girl.net est temporairement 
hors service a cause du debordement de la file d'attente des messages a acheminer. office.smartpservice 
.com rejette le message A et envoie a nice.guy.netle message d'erreur B (figure 7-10) suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : S0AP-ENV=" http://schemas.xmlsoap.org/soap/envelope/"> 
<S0AP-ENV:Body> 
<SOAP-ENV:Fault> 

<faultcode>SOAP-ENV:Server</faultcode> 
<faultstring> Message queue overflow</faultstring> 
<faultactor>http://office.smartpservice.com/</faultactor> 
<detail xml ns:d="http: //of fice.postalservice.com/details"> 

<d:suggestion>Try later</d:suggestion> 
</detail> 
</SOAP-ENV:Fault> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Lagestion des situations d'eiTeur de type VersionMismatch, MustUnderstand et Client ne pose pas de 
probleme particulier, car ces situations sont detectables a la simple analyse du message en erreur. II 
est possible pour le recepteur du message en erreur de suivre strictement les consignes du profil de 
base WS-I, a savoir rejeter le message (et eventuellement envoyer un message d'erreur) tout de suite 
apres analyse et avant tout traitement. Lacte de communication vehicule par le message est en echec 
et il n'y a pas d'effets de Facte sur le recepteur, excepte les effets techniques de type inscription dans 
le journal d'exploitation. 

En revanche, la gestion des situations d'erreur de type Server peut se reveler beaucoup plus delicate. 
Dans ces situations, les conditions de succes de Facte de communication sont accomplies et ce sont 
les conditions de satisfaction du meme acte qui ne le sont pas. Lexemple ci-dessus ne pose pas de 
probleme particulier car la situation apres levee de F erreur est la meme que celle avant F envoi du 
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message A. Mais dans le cas le plus general, la pragmatique (les effets sur le recepteur) de l'acte de 
communication vehicule par le message peut impliquer des changements d'etats et des effets de bord 
qui sont effectues comme consequences de la reception du message en erreur, mais avant que la situation 
d'erreur Server se declare. 

Quel est le statut de ces changements d'etat et de ces effets de bord apres defaillance et reconnaissance 
de la part du recepteur de la situation d'erreur Server correlee avec le message en erreur ? La gestion 
des traitements associes a la reception d'un message comme une unite de travail trans actionnelle 
permet de resoudre le probleme. La gestion transactionnelle des traitements associes a la reception 
des messages ramene la situation de non-satisfaction de Facte de communication a la situation 
d'echec du meme acte : c'est comme si l'acte n'avait jamais ete effectue. 
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Echanger avec un service - 
Codage des donnees 



Les services Web sont mis en ceuvre par des programmes ecrits a l'aide de differents langages de 
programmation. Ces langages manipulent des donnees atomiques comme les entiers, les flottants, les 
dates, etc., mais aussi des structures de donnees plus complexes, formees par composition recursive 
de donnees atomiques. 

Les donnees manipulees par les langages de programmation sont toujours typees. Elles le sont forcement 
dans les langages statiquement types, comme Java, C# ou C++, ou chaque variable doit declarer son 
type statiquement, c'est-a-dire dans le texte du programme. Une variable ne peut accueillir comme 
valeur qu'une donnee de son type (ou eventuellement d'un sous-type). 

Les donnees sont egalement typees dans les langages de programmation dynamiquement types, 
comme Ecmascript et Smalltalk, ou les variables ne declarent pas de type pour leur valeur et peuvent 
accueillir des donnees de tout type. La difference avec les langages statiquement types est que, dans 
ces derniers, les erreurs de type, c'est-a-dire l'application incorrecte d'un operateur ou d'une procedure 
a une donnee, peuvent etre detectees a la compilation du programme. 

SOAP 1 . 1 est cense mettre en ceuvre un mecanisme d'echange independant des choix d' implementation 
des applications, et notamment des langages de programmation. Ce mecanisme repose sur des messages 
au format XML dotes d'une structure predefinie (enveloppe, en-tete, corps, etc.). Pour faciliter l'inte- 
gration de ce mecanisme avec les applications, notamment avec les applications patrimoniales, il est 
interessant de definir des representations (codage) dans les messages SOAP des donnees manipulees 
par ces langages et applications et de mettre en ceuvre les regies associees d'encodage et de decodage. 

SOAP 1.1 appelle ces representations et les regies d'encodage/decodage associees des styles de 
codage {encoding style). A partir de la disponibilite d'un style de codage, des outils d'aide au develop- 
pement de services Web peuvent generer automatiquement la chaine des traitements, depuis la 
production du message SOAP de la part de l'emetteur, jusqu'a la consommation du message de 
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la part du recepteur. L'objectif est que le developpeur applicatif puisse continuer a travailler dans la 
representation de donnees propre au langage de programmation qu'il utilise, sans se poser de 
questions au sujet du format et du codage des donnees dans le message SOAP. 

Outre le codage des donnees, se pose le probleme de la transmission de fichiers binaires, qui vehiculent 
des objets multimedias. Nous verrons qu'il existe une technique d'encodage pour emboiter n'importe 
quelle chaine de bits dans un message SOAP. Cette technique presente des inconvenients en termes 
de performances car elle impose de lourdes taches d'encodage et de decodage, et provoque une 
augmentation de la taille de l'objet code et done de la charge reseau. 

La solution alternative est de transmettre les fichiers binaires sous forme de pieces jointes au message 
SOAP. Les fichiers sont transmis tels quels, sans etapes d'encodage/decodage ni augmentation de la 
taille. 

Ce chapitre presente la problematique du codage de donnees dans les messages et l'approche 
« pieces jointes », laquelle permet la transmission d' objets binaires avec un message SOAP. 

Le style de codage dans les messages SOAP 

Comment representer les donnees typees dans les messages SOAP ? Trois strategies sont possibles : 

• representation litterale ; 

• representation codee explicite ; 

• representation codee implicite. 

Representation litterale 

Avec la representation litterale, il n'y a pas de codage des donnees : le contenu XML du message 
SOAP (corps, entree de l'en-tete) est la donnee vehiculee par le message. 

Le producteur du message a la responsabilite de constituer un fragment XML bien forme et eventuel- 
lement valide et de le placer a la bonne position dans le message (comme descendant direct du corps 
ou comme une entree de l'en-tete). 

Le consommateur doit analyser le contenu du message. II peut accomplir cette tache a l'aide d'outils 
standards, disponibles dans plusieurs langages de programmation, comme les analyseurs syntaxiques 
SAX et DOM. II peut, par ailleurs, valider le message par rapport a un schema XML. Le consommateur 
peut egalement, avec les outils appropries, constituer en memoire une representation arborescente 
DOM du document obtenu pour des traitements ulterieurs. 

Deux applications qui s'echangent des messages SOAP 1.1 en representation litterale manipulent 
directement des fragments de documents XML. On peut surtout s'attendre a F utilisation de la repre- 
sentation litterale dans les nouvelles applications mettant en ceuvre les services Web. 

D'un cote, les organisations professionnelles et les organismes de standardisation concoivent 
aujourd'hui des documents metier type en format XML. Ces documents ou des fragments de ces 
documents peuvent etre echanges via SOAP, soit dans le corps et les entrees de l'en-tete du message, 
soit en tant que pieces jointes. Ces documents sont etablis et manipules par des utilisateurs humains 
via des interfaces homme/machine et, du fait de 1' automation des processus metier, par des programmes. 
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De 1' autre cote, des environnements de developpement centres sur une representation directement 
XML des donnees metier et de leur presentation dans les interfaces homme/machine se developpent 
et il est raisonnable de prevoir qu'ils gagneront en popularite et en diffusion, effacant ainsi les 
frontieres artificielles entre « donnee », « objet » et « document » metier. 

La representation litterale est done bien adaptee aux nouvelles applications qui utilisent XML et 
DOM comme format de representation natif des donnees metier. 



Une initiative OASIS : UBL (Universal Business Language) 

UBL est une bibliotheque standard, librement disponible, de documents type metier XML (commande, facture, etc.) 
qui se positionne comme federatrice des principales initiatives existantes dans le domaine. L'ambition affichee est 
qu'UBL devienne le standard international du commerce electronique et des echanges interentreprises. 
Le 27 Janvier 2003 le Technical Committee UBL d'OASIS (http://www.oasis-open.org/committees/ubl) a publie le 
draft de \'UBL Library Content (voir http://oasis-open.org/committees/ubl/lcsc/0p70/UBL0p70.zip). Ce comite est 
anime par Jon Bosak (Sun Microsystems), considere comme I'initiateur d'XML. 



Representation codee explicite 

En representation codee explicite, il existe un accord (tacite ou formalise) entre les applications qui 
participent a l'echange. Cet accord definit un style de codage, a savoir une correspondance entre, 
d'un cote, les arbres d'elements et les donnees-caracteres XML du message SOAP 1.1, et de l'autre, 
les types atomiques et structures manipules par les langages des applications participantes. La 
reference au style de codage est explicite dans le message. 

Loutil permettant d'indiquer le style de codage dans le message SOAP 1.1 est Fattribut SOAP-ENV: 
encodingStyle, dont la valeur est une liste d'URI separes par des espaces. Lattribut SOAP-ENV: encoding- 
Style est utilise dans les « revendications » de style de codage. 

La declaration SOAP-ENV:encodingStyle="[/W indique que le style de codage identifie par URI est en 
vigueur dans la partie du message couverte par la portee de la declaration. 

La declaration SOAP-ENV:encodingStyle="(/Ri"A' URIY ... URIZ" indique que les styles de codage identifies 
par URIX, URIY... URIZ sont appliques a la partie du message couverte par la portee de la declaration. 
L'ordre des styles est dans le sens du plus specifique au moins specifique : cela signifie que, pour 
decoder une representation dans le message, la regie de decodage qui s' applique est la premiere que 
Ton trouve dans les styles de la liste parcourue de gauche a droite. 

La declaration SOAP-ENV:encodingStyle="" affirme explicitement qu'il n'y a aucune revendication de 
style de codage dans la partie du message couverte par la portee de la declaration (cela ne veut pas 
dire qu'aucun style de codage n'est applique). 

La portee des revendications de style de codage suit les memes regies que les declarations de vocabulaires 
XML par defaut (sans prefixe). La declaration S0AP-ENV:encodingStyle="W?L4 URIB ... URIC" couvre 
l'arbre d'elements dont la racine est l'element dans lequel apparait la declaration, moins les parties 
(sous-arbres) couvertes par les portees : 

• d'autres declarations de type S0AP-ENV:encodingStyle="(//?7X URIY ... URIZ", qui revendiquent, pour 
toutes les parties des sous-arbres couvertes par leurs propres portees, d'autres styles de codage ; 
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• des declarations de type SOAP- ENV : encodi ngStyl e=" " qui affirment, pour toutes les parties des sous- 
arbres couvertes par leurs propres portees, 1' absence de revendication de style de codage. 

La definition de portee est recursive : les portees des declarations, dans les sous-arbres ou elles sont 
effectuees, suivent la regie que Ton vient d'enoncer. 

II n'y a pas de revendication de style de codage par defaut. L' absence de declaration de style de codage 
signifie que Femetteur du message ne revendique aucun style de codage (ce qui ne veut pas dire 
qu'aucun style de codage n'est applique au message implicitement). 

Representation codee implicite 

En representation codee implicite, les donnees sont codees dans le message selon un style de codage, 
mais celui-ci reste implicite, car le message ne vehicule aucune revendication explicite sur la 
presence d'un codage dans le message et aucune reference aux regies correspondantes d'encodage/ 
decodage. 

Dans un message SOAP 1.1, cela se traduit par l'absence de la declaration SOAP-ENV:encodingStyle 
ou par la presence de declarations de type : 

SOAP- ENV: encodi ngStyle="" 

qui affirment explicitement qu'il n'y a aucune revendication explicite de style de codage dans leurs 
portees respectives. 

Strategies de codage 

La specification SOAP 1.1 ne se limite pas a indiquer les mecanismes qui permettent de revendiquer 
les styles de codage dans les messages SOAP : elle propose aussi un style de codage, inclus dans la 
specification, que nous designons comme style de codage SOAP 1.1. 

Avant de presenter le style de codage SOAP 1.1, il est peut etre utile de revenir brievement sur le 
concept meme de style de codage. 

Le producteur du message genere une representation codee des donnees qu'il manipule et qu'il veut 
installer dans le message. Le consommateur du message decode la representation codee pour extraire 
les donnees. Ce processus est generalement mis en ceuvre a l'aide de deux strategies generates de 
codage : 

• Receiver-makes-right : dans cette approche, la procedure de decodage du consommateur est 
capable de decoder les representations codees specifiques, propres aux differents langages de 
programmation. Le producteur encode le message dans sa representation codee specifique. 

• Representation universelle : avec cette methode, le message est encode dans une representation 
unique pour tous les langages de programmation par Femetteur et decode a partir de ce format par 
le recepteur. 

Dans la premiere approche, pour chacun des N langages participants, il existe une procedure 
complexe de decodage et N procedures d'encodage/decodage simples, pour un total de N(N+1) 
procedures. Dans ce cas, le producteur du message ne connait pas forcement le langage de program- 
mation du consommateur, mais, par exemple, un agent qui agit comme un serveur SOAP (au sens de 
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cible de requetes qui demandent des reponses) est oblige de connaitre les langages de programmation 
de ses clients pour pouvoir encoder correctement les reponses. II s'agit la d'une contrainte de 
couplage non negligeable. 

Dans la seconde approche, chaque langage de programmation met en ceuvre une procedure d'encodage 
vers la representation universelle et une procedure de decodage a partir de cette representation. Pour 
N langages de programmation, cela represente un total de 2N procedures. Dans ce cas, le serveur n'a 
pas besoin de connaitre les langages de programmation utilises par ses clients. Cette approche est 
evidemment preferable lorsqu'il s'agit de garantir l'interoperabilite entre applications faiblement 
couplees et mises en ceuvre dans des langages de programmations differents. 

La representation universelle demande cependant un effort de conceptualisation important. Pour 
fonctionner, elle doit etre le resultat de la generalisation des differents systemes de types, atomiques 
et structures, et des differents langages de programmation. 

Lorsque le meme langage de programmation est utilise chez les deux interlocuteurs de l'echange, une 
representation ad hoc des procedures d'encodage/decodage, qui s'adaptent parfaitement aux specifi- 
cites du langage, presente un avantage en termes de performance par rapport a la representation 
universelle qui peut ne pas etre negligeable. C'est ce qui se produit avec la representation JRMP, 
utilisee par RMI (Remote Method Invocation), qui permet a des programmes Java distants de 
s'echanger de facon optimisee des informations sur le reseau (sous forme d'invocations de methodes 
sur des objets distants). 

Dans le cadre de SOAP 1.1, les deux approches sont en principe viables. On peut imaginer, dans le 
but d'optimiser les echanges entre applications ecrites dans le meme langage, un style de codage 
specifique a chaque langage de programmation. Un service Web peut publier des interfaces differentes 
ou, pour la meme interface, plusieurs liaisons (bindings) avec un style de codage universel et une 
liaison optimisee pour son langage d' implementation. Les applications ecrites dans le meme langage 
de programmation peuvent dialoguer de facon optimisee avec le service Web en question, sans perte 
de generalite. 

Les objectifs du style de codage SOAP 1.1 

Lobjectif premier des technologies de services Web est 1'interoperabilite des applications : le style 
de codage propose par SOAP 1.1 est une representation universelle qui repose sur un systeme de 
types des donnees atomiques et sur une technique de serialisation de graphes pour les donnees struc- 
turees. 

Cette representation universelle est evidemment independante des langages de programmation 
susceptibles de mettre en ceuvre les applications impliquees dans l'echange. La specification 
SOAP 1 . 1 revendique le fait que le systeme de typage pivot qu'elle propose est issu d'une generalisation 
des traits communs aux systemes de typage des langages de programmation les plus repandus. 

La specification SOAP 1.1 precise que le style de codage SOAP 1.1 (celui qui est expose dans la 
section 5 de la specification) est identifie par l'URI http://schemas.xmlsoap.org/soap/encoding/, et 
que les messages qui adoptent ce style de codage devraient le revendiquer explicitement, a savoir 
indiquer cet usage par la declaration : 

SOAP- ENV:encodingStyle=" http://schemas.xml soap.org/soap/encoding/" 
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En outre, tous les URI dont la chaine de caracteres commence par http://schemas.xmlsoap.org/ 
soap/encoding/ indiquent par convention la conformite avec le style de codage SOAP 1.1, avec 
eventuellement des regies plus contraignantes. 

Typage dynamique 

Un objectif important du style de codage SOAP 1.1 est de permettre a deux applications de s'echanger 
des donnees « dynamiquement » typees. Cela signifie qu'une application SOAP consommatrice doit 
etre capable de decoder des donnees dont les types sont decouverts a la volee lorsqu'elle analyse le 
message, sans connaissance prealable des types de donnees impliques dans un echange particulier. 
Cette fonctionnalite est utile pour permettre V echange d'objets par valeur entre programmes ecrits 
dans des langages dynamiquement types : le type d'un parametre passe par valeur dans un appel 
distant de methode Smal 1 tal k n'est pas predetermine et done doit etre reconnu dynamiquement par le 
recepteur, car celui-il doit reconstruire en memoire la structure de donnees appropriee. 

Cela permet a deux applications de s'echanger des messages dont le contenu peut etre mis en 
correspondance dynamique avec les donnees atomiques et structurees manipulees par les langages 
des applications concernees. Ce fonctionnement est obtenu par F annotation explicite (directe ou par 
indirection) des types dans les representations des donnees vehiculees dans le message. 

Serialisation de structures partagees et circulaires 

Un deuxieme objectif du style de codage SOAP 1.1 est d'offrir la capacite de serialisation de structures 
de donnees partagees et circulaires. Cet objectif est atteint par l'introduction dans le codage d'un 
mecanisme general de referencement d'un element du message vers le contenu d'un autre element, 
qui permet d'indiquer que ce contenu est partage, a savoir qu'il appartient aux deux elements. 

Les bases du style de codage SOAP 1 .1 

Lors de Fecriture de la premiere specification SOAP, la technologie des services Web etait a ses 
debuts et F objectif primaire de SOAP etait principalement d'apporter une meilleure integration entre 
les technologies des objets et des composants repartis, comme DCOM, CORBA et RMI, ainsi 
qu'avec les technologies Internet comme XML et HTTP. L' objectif etait de construire un mecanisme 
de codage des donnees dans les messages qui reposent sur XML, a la place des differents systemes de 
codage binaire utilises par DCOM, CORBA et RMI (respectivement NDR, CDR et JRMP). 

Pour atteindre ce resultat, la technologie XML Schema ne pouvait etre utilisee, et cela pour plusieurs 
raisons : 

• lorsque la specification SOAP 1.1 est sortie sous forme d'une note adressee au W3C, le 8 mai 
2000, la specification XML Schema etait encore a Fetat de working draft ; 

• des types generiques comme les vecteurs (arrays) et les structures n'etaient pas dans le perimetre 
de la specification ; 

• la specification, en Fetat, ne comprenait pas de mecanisme permettant de definir des structures de 
graphe (partagees et circulaires). 
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La specification SOAP 1.1 choisit done de definir le style de codage SOAP 1.1 (section 5 du document) 
par le biais de la definition d'un modele de donnees abstrait SOAP 1.1. 

Les regies de codage SOAP 1.1 se chargent de la correspondance entre le modele de donnees 
SOAP 1.1 et le format de message SOAP 1.1. Le modele de donnees SOAP 1.1 est done le modele 
pivot. La correspondance entre chaque langage de programmation et le modele de donnees SOAP 1 . 1 
releve de la responsabilite des developpeurs des differentes plates-formes. 

Lorsque le concept de service Web a commence a emerger, le probleme du langage de description du 
format de message s'est pose. La technologie des services Web s'est alors appuyee sur la specification 
WSDL 1.1, presentee chapitre 10. 

Les auteurs de la specification WSDL ont retenu comme langage par defaut de description des types 
abstraits de donnees le systeme de typage XML Schema : XML Schema Datatypes (XSD). En meme 
temps, le style de codage SOAP 1.1 avait deja ete mis en ceuvre sur plusieurs plates-formes et il 
fallait done pouvoir le referencer dans la description des interfaces en WSDL. 

Le centre du probleme est que le metalangage XSD ne peutpas rendre compte seal de la semantique 
du style de codage SOAP 1.1. En fait, XSD permet de representer l'information comme un arbre 
d' elements statiquement types, alors que le style d'encodage SOAP 1.1 la represente comme un 
graphe de structures dynamiquement typees. La solution optimale de ce probleme serait la mise en 
ceuvre d'un mecanisme general de representation des graphes dans le cadre d'une prochaine version 
de XML Schema. 

La solution retenue par le style de codage SOAP 1 . 1 consiste a definir les types en XSD dans la partie 
« interface abstraite » du document WSDL (sous l'element types) et de specifier l'usage du style de 
codage SOAP 1.1, eventuellement de facon precise pour chaque message, dans la partie « liaison » 
(sous l'element binding) via Fattribut use. Ainsi, la valeur literal de use signifie que le schema XSD 
dans l'element WSDL types est une specification concrete du codage des donnees dans le message, 
alors que la valeur encoded signifie que les elements du schema XSD dans l'element WSDL types 
represented une specification abstraite de ce qui va apparaitre dans le corps des messages et que la 
semantique operationnelle des structures concretes (notamment la reconstruction en memoire de 
structures partagees et circulaires a partir du « texte » du message) ne peut etre comprise qu'avec 
l'application des regies propres au style de codage (encodingStyle). 

II faut noter que lorsque, dans le document WSDL de description de F interface d'un service, la valeur 
de use est encoded, ce service s'attend a ce que les donnees soient codees dans les messages SOAP 
suivant le style de codage designe par la valeur d'encodingStyle, et cela independamment de la 
presence ou non de revendications de styles de codage dans les messages (qui ne sont pas obligatoires, 
mais seulement recommandees). 



Technologies des services Web 

Deuxieme Partie 



Schema XML du style de codage SOAP 1.1 et espaces de noms des exemples 

Le style de codage SOAP 1.1, lorsqu'il est utilise dans les exemples qui suivent, doit etre considere revendique par 
la declaration d'usage 

SOAP-ENV:encodingStyl e=" http://schemas.xml soap.org/soap/encoding" 
Martin Gudgin (Developmentor) a redige en 2001 un schema XML pour le style de codage SOAP 1.1 (qui definit 
les vecteurs, les structures, les attributs qui mettent en ceuvre le mecanisme de referencement, etc.) conforme a la 
recommandation de XML Schema. Ce schema est accessible par I'URL http://schemas.xmlsoap.org/soap/encoding, 
qui est egalement I'identifiant du style de codage SOAP 1.1 et le lien est actif sur la page officielle presentant la 
note Simple Object Access Protocol (SOAP) 1. 1, W3C Note 08 May 2000 (http://www.w3.org/TR/S0AP). Les fragments 
de schema repris dans les exemples sont tires de ce document. Nous appelons ce schema « schema de codage 
SOAP 1.1 ». 

Les structures de donnees propres au style de codage et definies dans le schema de codage SOAP 1.1 seront 
prefixees par SOAP-ENC, qui designe un vocabulaire XML du meme nom que le style de codage (http: //sche- 
ma s.xml soap.org/soap/encoding). 

Les prefixes xs et xsi designent respectivement http://www.w3.org/2001/XMLSchema et http:// 
www.w3.org/2001/XMLSchema-instance. 

Nous utiliserons systematiquement le prefixe tns dans les fragments de schema XML pour les noms des types, 
des elements et des attributs definis dans le schema. Ce prefixe designe le vocabulaire XML (targetNamespace) 
du schema lui-meme. 

Dans les fragments de message des exemples les noms definis dans le schema applicatif seront qualifies par ens 
(example namespace). 



Le modele de donnees du style de codage SOAP 1.1 

La specification SOAP 1.1 designe les donnees codees dans un message sous le terme de valeurs. 
Une valeur peut etre une valeur simple, en correspondance avec les donnees atomiques, ou bien une 
valeur composite (en correspondance avec les donnees structurees). 

Une valeur est toujours representee dans un message SOAP (en-tete, corps, erreur) comme le contenu 
d'un element XML. 

Une valeur simple est representee par les donnees-caracteres du contenu d'un element « feuille », qui 
n'a pas de sous-elements. Une valeur simple est toujours typee. Voici un exemple de valeur simple : 

<ens :accountcode>0000123456A</ens: account code> 
L'element dont Foccurrence est presentee ci-dessus est defini dans le schema ens : 

<element name="accountcode" type="string"/> 

Une valeur composite est un agregat recursifde valeurs simples, comme : 

<ens:customer> 
<ens:names> 

<ens :name>Jean</ens : name> 

<ens:name>Charles</ens:name> 

<ens:name>Del arochefoucauld</ens:name> 
</ens:names> 
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<ens:RIB> 

<ens:bankcode>4000K/ens:bankcode> 

<ens:positioncode>00987</ens:positioncode> 

<ens:accountcode>0000123456A</ens: account code> 

<ens: control key>92</ens: control key> 
</ens:RIB> 
</ens:customer> 

Chaque valeur simple agregee dans une valeur composite est distincte des autres soit par un nom, soit 
par une position relative, soit par les deux. Le nom associe d'une valeur est appele accesseur : 
accountcode est l'accesseur de 0000123456A. La portee des noms pour les valeurs composantes d'une 
valeur composite peut etre locale a la valeur composite (en fait au couple type/valeur composite, 
comme on le verra par la suite) ou universelle, pour tout le message. 

Le style de codage SOAP introduit deux sortes de valeurs composites « generiques » : 

• la structure SOAP ; 

• le vecteur SOAP. 

Une structure SOAP est une valeur composite dans laquelle le nom de l'accesseur represente sans 
ambiguite une et une seule valeur membre : 

<ens:RIB> 

<bankcode>4000K/bankcode> 

<positioncode>00987</positioncode> 

<accountcode>0000123456A</accountcode> 

<control key>92</control key> 
</ens:RIB> 

Un vecteur SOAP est une valeur composite dans laquelle deux valeurs membres ne peuvent etre 
differenciees que par leur position relative, sequentiellement obtenue a partir du debut du vecteur 
(1' ordinal). 

<ens:names> 

<name>Jean</name> 

<name>Charl es</name> 

<name>Del arochefoucauld</name> 
</ens:names> 

Le style de codage SOAP 1 . 1 accepte des valeurs composites generiques dans lesquelles le meme nom 
d' accesseur peut designer plusieurs valeurs membres et, a 1' inverse, par un mecanisme de referencement 
que Ton verra par la suite, plusieurs noms d'accesseurs peuvent designer la meme valeur membre. 

Chaque valeur est annotee, directement ou indirectement, par un type. Un type simple est une classe 
de valeurs simples, comme la classe des entiers, des chaines de caracteres, etc. Un type simple est, 
soit un type built-in de la specification XML Schema Datatypes (XSD), soit un type derive d'un type 
built-in. Un type composite est une classe de valeurs composites. 

Les valeurs et les types simples 

Le style de codage SOAP s'appuie sur le systeme de typage de donnees atomiques propose par la 
specification XML Schema. 
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XML Schema Datatypes (XSD) definit chaque type par un espace de valeurs et un espace lexical. Par 
exemple, l'espace de valeurs du type nonNegativelnteger est forme par Fensemble des entiers positifs 
plus le zero. Chaque valeur est exprimee par un ou plusieurs litteraux, expressions (chaines de carac- 
teres) appartenant a l'espace lexical du type. L'espace lexical d'un type est l'ensemble des litteraux 
valides pour le type en question : par exemple, l'espace lexical du type nonNegati velnteger est consti- 
tue des chaines de caracteres formees a partir des caracteres 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 . Les elements de 
l'espace lexical (litteraux) 1, 01, 001, etc. represented l'element « 1 » de l'espace des valeurs des 
entiers non negatifs. 

Les types built-in proposes par la specification XSD sont listes dans le tableau 8-1 (dans lequel nous 
ne precisons pas les espaces lexicaux, mais seulement les espaces de valeurs). 

predefinis de XML Schema Datatypes 

Description de l'espace des valeurs 

Les sequences finies de caracteres qui s'apparient avec la production 
Char de XML 1.0 (Second Edition) . Un caractere est une unite atomique 
de communication et est la base (rock-bottom) de la specification. 

L'espace de valeur de verite de la logique binaire. 

Les nombres decimaux a precision arbitraire. 

Les nombres a virgule flottante en simple precision (IEEE 754 - 1 985). 

Les nombres a virgule flottante en double precision (IEEE 754 - 1985). 

Les durees en annees, mois, jours, heures, minutes, secondes (ISO 8601 ). 

Les instants de temps en date et heure du jour (Combination of date 
and time of day -ISO 8601). 

Les instants de temps en heure du jour (Time of day- ISO 8601). 

Les dates calendaires (Gregorian calendar date - ISO 8601). 

Les dates en annees et mois (Gregorian calendar date - ISO 8601). 

Les dates en annees ( Gregorian calendar date - ISO 8601 ). 

Les dates en mois et jours ( Gregorian calendar date - ISO 8601 ). 

Les dates en jours (Gregorian calendar date - ISO 8601). 

Les dates en mois (Gregorian calendar date - ISO 8601). 

Les nombres binaires en caracteres hexadecimaux. 

Les nombres binaires en Base 64 (IETF - RFC 2045). 

Les URI (IETF - RFC 2396, RFC 2732). 

Les noms XML qualifies (Namespaces in XML). 

Type de I'attribut NOTATION (XML 1 .0). 

Les chaines de caracteres sans retour chariot, a la ligne ou tab 
(« normalisees espace »). 

Les chaines de caracteres « normalisees espace » sans espace en 
suffixe ou prefixe et sans sous-chaine de deux espaces ou plus. 





Tableau 8-1 . Les types | 


Type 


Type de base 


string 


(primitif) 


boolean 


(primitif) 


decimal 


(primitif) 


float 


(primitif) 


double 


(primitif) 


duration 


(primitif) 


dateTime 


(primitif) 


time 


(primitif) 


date 


(primitif) 


gYearMonth 


(primitif) 


gYear 


(primitif) 


gMonthDay 


(primitif) 


gDay 


(primitif) 


gMonth 


(primitif) 


hexBinary 


(primitif) 


base64Binary 


(primitif) 


anyURI 


(primitif) 


QName 


(primitif) 


NOTATION 


(primitif) 


normal izedString 


string 



token 



normal izedString 
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Tableau 8-1. Les types predefinis de XML Schema Datatypes (suite) 

Description de I'espace des valeurs 

Les identifiants de langue (IETF - RFC 1 766). 

Type de I'attribut NMTOKEN (XML 1 .0). 

Sequences d'occurrences de NMTOKEN separes par des espaces. 

Les noms XML (XML 1.0). 

Un nom XML non qualifie par un prefixe representant un espace de noms. 

Type de I'attribut ID (XML 1.0). 

Typede I'attribut IDREF (XML 1.0). 

Sequences d'occurrences de IDREF separees par des espaces. 

Typede I'attribut ENTITY (XML 1.0). 

Sequences d'occurrences de ENTITY separes par des espaces. 

Les entiers. 

Les entiers negatifs et le zero. 

Les entiers negatifs. 

Les entiers compris entre -9223372036854775808 et 
9223372036854775807. 

Les entiers compris entre -2147483648 et 2147483647. 

Les entiers compris entre -32768 et 32767. 

Les entiers compris entre -128 et 127. 

Les entiers positifs et le zero. 

Les entiers compris entre et 18446744073709551615 inclus. 

Les entiers compris entre et 4294967295. 

Les entiers compris entre et 65535. 

Les entiers compris entre et 255. 

Les entiers positifs. 



Type 


Type de base 


1 anguage 


token 




NMTOKEN 


token 




NMT0KENS 


(Liste de) 


NMTOKEN 


Name 


token 




NCName 


Name 




ID 


NCName 




IDREF 


NCName 




IDREFS 


(Liste de) 


IDREF 


ENTITY 


NCName 




ENTITIES 


(Liste de) 


ENTITY 


integer 


decimal 




nonPositivelnteger 


integer 




negati velnteger 


nonPosit 


ivelnteger 


long 


integer 




int 


long 




short 


int 




byte 


short 




nonNegativelnteger 


integer 




unsignedLong 


nonNegat 


ivelnteger 


unsignedlnt 


unsignedLong 


unsignedShort 


unsignedlnt 


unsignedByte 


unsignedShort 


positi velnteger 


nonNegat 


ivelnteger 



Le typage d'une valeur simple 

Nous avons vu qu'une valeur simple est toujours representee par le contenu donnees-caracteres d'un 
element XML. A priori, le type de la valeur est inconnu : la meme chaine de caracteres 001 peut etre 
interpretee comme un type nonNegativelnteger ou un type string. 

SOAP 1.1 impose Fannotation du typage des valeurs simples dans le message et propose trois approches 
pour designer les types : 

• le typage implicite, qui correspond au renvoi, par le vocabulaire XML, a un schema XML Schema, 
qui contient la definition de F element et de son type ; 

• le typage explicite, qui entraine Futilisation de I'attribut xsi :type dans Felement accesseur a la 
valeur (et, comme nous verrons par la suite, S0AP-ENC:arrayType pour le type des elements d'un 
vecteur) ; 
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• le typage non standard, qui correspond ail renvoi, par le vocabulaire XML, de l'accesseur a un 
systeme de typage differente de XSD. 

Le typage implicite (par renvoi a un schema XSD) 

Le renvoi a un schema XSD se fait par le biais du vocabulaire XML de l'accesseur associe au schema 
en question (qui doit designer l'espace des noms d'un schema XML) : 

I <ens: account code xmlns:ens="http://example.org/schema.xsd"> 
0000123456A 
</ens:accountcode> 

Dans le schema, F element accountcode est ainsi defini : 

<xs:element name="accountcode" type="xs:string"/> 

Le typage explicite 

Le type peut aussi etre directement designe via l'attribut xsi :type : 

<ens: accountcode xsi :type="xs:string">0000123456A</ens:accountcode> 

Le style de codage SOAP 1.1 admet des accesseurs polymorphes (dans le meme message), a savoir 
la reutilisation des accesseurs pour plusieurs donnees de types differents. La specification SOAP 1.1 
impose dans ce cas Futilisation de xsi :type sur chaque occuiTence de l'accesseur en question. Par 
exemple : 

<ens:cost xsi :type="xs: decimal ">29.95</ens:cost> 
<ens:cost xsi :type="xs:float">29.95</ens:cost> 
I <ens:cost xsi :type="xs :double">29.95</ens:cost> 

Le typage non standard 

Le type peut encore etre indirectement designe par reference a un systeme de typage qui ne suit pas 
la specification XSD via le vocabulaire XML de l'accesseur : 

I<eens:accountcode 
xmlns:eens="http: //example. org/ NonXMLSchema.nxs">0000123456A</eens:accountcode> 

http://example.org/NonXMLSchema.nxs est le nom d'un vocabulaire XML associe a un systeme de 
schema different de XSD. 

Les valeurs simples plurireferencees 

Le style de codage SOAP 1.1 propose un mecanisme generalise de referencement qui permet le 
partage des structures de donnees a l'interieur du message. Nous avons vu que lorsqu'une valeur 
simple est contenue dans une cascade de valeurs composites, elle peut etre representee par son accesseur, 
ou eventuellement par une cascade d' accesseurs. Cette valeur n'est pas a priori partageable par une 
autre structure du meme message : le constructeur du message est oblige de reproduire une structure 
syntaxiquement egale. 
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Voici un exemple : 

<ens:customer> 

<ens:name>Mathieu Duquesnoy</ens:name> 

<ens: account code xsi :type="xs:string">0000123456A</ens : account code> 
</ens:customer> 
<ens:customer> 

<ens :name>Georgette Grosei 1 1 e</ens : name> 

<ens: account code xsi :type="xs:string">0000123456A</ens : account code> 
</ens:customer> 

Les deux occurrences de la valeur 0000123456A de type built-in xs : string avec accesseur accountcode 
sont dites monoreferencees. Les deux occurrences sont syntaxiquement egales. Pour signifier 
qu'elles sont identiques, le style de codage SOAP 1.1 nous fournit les outils necessaires. 

Mecanisme generalise de referencement SOAP 1.1 

Le style de codage SOAP 1.1 propose des mecanismes qui permettent de referencer plusieurs fois 
une valeur, et done de la « partager » : la valeur devient plurireferencee. Ces mecanismes reposent 
tous sur 1' utilisation des attributs id et href, dont la definition dans le schema de codage SOAP 1.1 
(SOAP-ENC) est la suivante : 

<xs:attributeGroup name="commonAttributes"> 

<xs:attribute name="id" type="xs : ID"/> 

<xs:attribute name="href" type="xs:anyURI" /> 

<xs: any Attribute namespace="##other" processContents="lax"/> 
</xs :attributeGroup> 

Le schema associe au style de codage SOAP 1 . 1 contient : 

• des extensions pour tous les types built-in de XSD (voir le tableau des types built-in de XML 
Schema DataTypes) qui permettent d'utiliser les attributs id et href ; 

• les definitions d' elements qui vont permettre l'utilisation d'accesseurs anonymes (un accesseur 
anonyme est un element qui se nomme comme le type de sa valeur). 

En guise d'exemple, voici l'extension SOAP 1.1 pour le built-in xs : string : 

<xs: complexly pe name="string"> 
<xs:simpleContent> 

<xs: extension base="xs:string"> 

<xs:attributeGroup ref="tns:commonAttributes"/> 
</xs:extension> 
</xs:simpleContent> 
</xs :complexType> 
<xs:element name="string" type="tns :string"/> 
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Remarque sur le type xs : stri ng 

II est important de noter que le type built-in xs : stri ng de XSD ne correspond pas directement aux types string 
de plusieurs langages de programmation ou au type equivalent des bases de donnees. La specification XML 
Schema precise que les valeurs de xs : string correspondent aux chaines de caracteres generees par la regie de 
production Char de XML 1.0 (Second Edition). Cette specification interdit I'utilisation de certains caracteres que 
plusieurs langages permettent d'utiliser. 



Evolutions SOAP 1.2 (draft) 

Lattribut SOAP 1.1 href de type xs : anyURI est appele ref (type xs : IDREF) en SOAP 1.2. 



Plurireference par typage explicite 

Les accesseurs types explicitement par les types etendus SOAP peuvent nommer la meme valeur : 

<ens:customer> 

<ens:name>Mathieu Duquesnoy</ens:name> 

<ens:accountcode xsi :type="xs:string" id="myAccountcode"> 
0000123456A 

</ens:accountcode> 
</ens:customer> 
<ens:customer> 

<ens :name>Georgette Groseil le</ens:name> 

<ens:accountcode xsi :type="xs: string" href="#myAccountcode"/> 
</ens:customer> 

La valeur 0000123456A, dont Faccesseur est ens : accountcode possede maintenant un identifiant unique 
dans le message (valeur del' attribut id)myAccountcode. Pourcefaire, elle a comme valeur de xsi :type 
le type SOAP- ENC: string. Les deux accesseurs ens: accountcode, pour partager la valeur 0000123456A, 
utilisent les attributs id et href. 

Plurireference par typage implicite 

Une valeur plurireferencee peut etre indirectement typee, par renvoi a un schema XSD. Le schema 
XSD http://example.org/schema.xsd, contient la definition suivante : 

<xs:element name="accountcode" type="SOAP-ENC:string"/> 

Dans le message SOAP 1. 1, la valeur est designee par un accesseur appartenant au vocabulaire XML 
http://example.org/schema.xsd (prefixe ens) et peut etre directement partagee : 

<ens:customer> 

<ens:name>Mathieu Duquesnoy</ens:name> 

<ens: accountcode id="myAccountcode">0000123456A</ens:accountcode> 
</ens:customer> 
<ens:customer> 

<ens :name>Georgette Groseil le</ens:name> 

<ens: accountcode href="#myAccountcode"/> 
</ens:customer> 
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Plurireference par accesseur anonyme 

Le style de codage SOAP propose une troisieme technique pour partager une valeur. II est possible de 
placer une valeur typee dans un message avec accesseur anonyme, mais avec identifiant et pouvant 
par consequent etre referencee : 

<ens:accountcode id="myAccountcode">0000123456A</ens:accountcode> 
<ens:customer> 

<ens:name>Mathieu Duquesnoy</ens:name> 

<ens: account code href="#myAccountcode"/> 
</ens: customers 
<ens:customer> 

<ens :name>Georgette Grosei 1 1 e</ens : name> 

<ens: account code href="#myAccountcode"/> 
</ens: customers 

En fait, tout accesseur ayant le bon type etendu SOAP 1.1 (dote des attributs 1 d et href) peut referencer 
une occurrence d'une valeur du meme type. 

Les valeurs et les types composites 

Les valeurs simples qui appartiennent a une valeur composite sont toujours codees comme des 
elements. Si le nom de F accesseur est non ambigu (il permet de les distinguer), alors il est code comme 
nom de 1' element. 

Voici un exemple : 

<ens:RIB> 

<bankcode>4000K/bankcode> 

<positioncode>00987</positioncode> 

<accountcode>0000123456A</accountcode> 

<control key>92</control key> 
</ens:RIB> 

L' element precedent est decrit par le schema suivant : 

<xs:element name="RIB" type="tns:RIBType"/> 
<xs:complexType name="RIBType"> 
<xs:sequence> 

<xs:element name="bankcode" type="tns:bankcodeType"/> 
<xs: element name="positioncode" type="tns:positioncodeType"/> 
<xs:element name="accountcode" type="tns:accountcodeType"/> 
<xs:element name="control key" type="tns:control keyType"/> 
</xs:sequence> 
</xs :complexType> 

<xs : simpl eType name="bankcodeType"> 
<xs: restriction base="xs:string"> 

<xs:length value="5" fixed="true"/> 
</xs: restriction> 
</xs : simpl eType> 

<xs: simpl eType name="positioncodeType"> 
<xs: restriction base="xs:string"> 
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<xs:length value="5" fixed="triie"/> 
</xs : restriction 
</xs:simpleType> 

<xs :simpleType name="accountcodeType"> 
<xs: restriction base="xs:string"> 

<xs:length value="ll" fixed="true"/> 
</xs : restriction> 
</xs:simpleType> 

<xs:simpleType name="control keyType"> 
<xs: restriction base="xs:string"> 

<xs:length value="2" fixed="true"/> 
</xs : restriction> 
</xs:simpleType> 

SOAP 1.1 definit deux types complexes generiques correspondant a deux constructions que Ton 
retrouve communement dans les langages de programmation : 

• les structures ; 

• les vecteurs. 



Structures 

Une structure est une valeur composite dans laquelle le nom de l'accesseur represente sans ambiguite 
la valeur membre. Les accesseurs des valeurs simples ont des noms differents, qui correspondent aux 
noms des elements. 

Schema de codage 

Voici la definition de la structure generique dans le schema de codage SOAP 1.1 : 

<xs:group name="Struct"> 
<xs:sequence> 

<xs:any namespace="##any" minOccurs="0" 

maxOccurs="unbounded" processContents="l ax"/> 
</xs :sequence> 
</xs:group> 

La definition du type complexe se presente ainsi : 

<xs:complexType name="Struct"> 

<xs:group ref="tns:Struct" minOccurs="0"/> 

<xs:attributeGroup ref="tns: common Attributes"/> 
</xs:complexType> 

SOAP-ENC:Struct est done une structure polymorphe. II faut noter que Finclusion de commonAttributes 
dans la definition du type SOAP-ENC:Struct permet de mettre en ceuvre le mecanisme generalise de 
referencement SOAP 1.1. 

Voici 1' element pour l'accesseur anonyme : 

<xs:element name="Struct" type="tns:Struct"/> 



Echanger avec un service - Codage des donnees 

Chapitre 8 

Exemples 

Un exemple de structure polymorphe a typage explicite des composants est detaille ci-apres : 

<ens:RIB xsi :type="SOAP-ENC:Struct"> 

<ens:bankcode xsi :type="xs:string">4000K/ens:bankcode> 

<ens:positioncode xsi :type="xs:string">00987</ens:positioncode> 

<ens: account code xsi :type="xs:string">0000123456A</ens:accountcode> 

<ens: control key xsi :type="xs:string">92</ens: control key> 
</ens:RIB> 

Voici le RIB en tant que structure typee dont les membres sont des accesseurs pour valeurs pluri- 
referencees : 

<xs:element name="RIB" type="tns:RIBStructType"/> 
<xs: complexly pe name="bankcodeType"> 
<xs:simpleContent> 

<xs: restriction base="SrjAP-ENC:string"> 

<xs:minLength value="0"/Xxs:maxLength value="5"/> 
</xs:restriction> 
</xs:simpleContent> 
</xs :complexType> 

<xs: complexly pe name="positioncodeType"> 
<xs:simpleContent> 

<xs: restriction base="SOAP-ENC:string"> 

<xs:minLength value="0"/Xxs:maxLength value="5"/> 
</xs:restriction> 
</xs:simpleContent> 
</xs :complexType> 

<xs : compl exType name="accountcodeType"> 
<xs:simpleContent> 

<xs: restriction base="SOAP-ENC:string"> 

<xs:minLength value="0'7Xxs:maxLength value="ll"/> 
</xs:restriction> 
</xs:simpleContent> 
</xs : compl exType> 

<xs : compl exType name="control keyType"> 
<xs:simpleContent> 

<xs: restriction base="SOAP-ENC:string"> 

<xs:minLength value="0"/Xxs:maxLength value="2"/> 
</xs:restriction> 
</xs:simpleContent> 
</xs : compl exType> 

<xs:element name="bankcodeType" type="tns:bankcodeType"/> 
<xs: element name="positioncodeType" type="tns:positioncodeType"/> 
<xs: element name="accountcodeType" type="tns:accountcodeType"/> 
<xs: element name=" control key Type" type="tns: control keyType"/> 
<xs:group name="RIBTypeGroup"> 
<xs:sequence> 

<xs:element name="bankcode" type="tns:bankcodeType"/> 

<xs: element name="positioncode" type="tns:positioncodeType"/> 

<xs:element name="accountcode" type="tns:accountcodeType'7> 
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<xs:element name="control key" type="tns:control keyType"/> 

</xs :sequence> 
</xs:group> 
<xs : complexly pe name="RIBStructType"> 

<xs:group ref="tns:RIBTypeGroup" minOccurs="0"/> 

<xs:attributeGroup ref="SOAP-ENC:commonAttributes"/> 
</xs:complexType> 

Pour definir facilement une structure typee, il suffit d'ajouter a la definition de chaque nceud les attributs 
de referencement id et href. Le fragment de schema suivant permet differentes formes de partage de 
valeurs : 

<ens: customer^ 

<ens:name>Mathieu Duquesnoy</ens:name> 
<ens:RIBs> 

<ens:RIB id="MyRIB"> 

<bankcode id="MyBankcode">4000K/bankcode> 
<positioncode id="MyPositioncode">00987</positioncode> 
<accountcode id="MyAccountcode">0000123456A</accountcode> 
<control key id="MyControl key">92</control key> 
</ens:RIB> 
<ens:RIB> 

<bankcode href ="#My Ban kcode"/> 
<positioncode href="#MyPositioncode"/> 
<accountcode>0000654321B</accountcode> 
<control key>29</control key> 
</ens:RIB> 
</ens:RIBs> 
</ens:customer> 
<ens:customer> 

<ens:name>Georgette Groseille</ens:name> 
<ens:RIBs> 

<ens:RIB href="#MyRIB'7> 
<ens:RIB> 

<bankcode href ="#My Ban kcode"/> 
<positioncode href="#MyPositioncode"/> 
<accountcode>0000123654B</accountcode> 
<control key>18</control key> 
</ens:RIB> 
<ens:RIB> 

<bankcode href ="#My Ban kcode"/> 
<positioncode>00789</positioncode> 
<accountcode>0000456321C</accountcode> 
<control key>8K/control key> 
</ens:RIB> 
</ens:RIBs> 
</ens:customer> 

Georgette Groseille et Mathieu Duquesnoy partagent un compte bancaire. Mathieu a ouvert un 
second compte a la meme banque et a la meme agence. Georgette a egalement ouvert un deuxieme 
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compte a la meme banque et a la meme agence, et elle a en outre un troisieme compte a la meme banque 
mais aupres d'une autre agence. 

Vecteurs 

Un vecteur (SOAP- ENC: Array) est une valeur composite dans laquelle la position (F ordinal) represente 
sans ambiguite les valeurs membres. Le terme « tableau » est utilise parfois a la place de vecteur. Une 
occurrence d'un vecteur SOAP est done une sequence ordonnee d' elements, dont les noms ne sont 
pas signifiants. 

Schema de codage 

On trouve tout d'abord le curseur d'un vecteur : 

|<xs : simpl eType name="arrayCoordi nate"> 
<xs: restriction base="xs :string"/> 
</xs : simpl eType> 

ensuite les attributs du vecteur : 

<xs:attribute name="arrayType" type="xs:string"/> 
<xs:attribute name="offset" type="tns:arrayCoordinate"/> 
<xs:attributeGroup name="arrayAttributes"> 

<xs: attribute ref="tns:arrayType"/> 

<xs: attribute ref="tns:offset"/> 
</xs :attributeGroup> 

SOAP-ENC:arrayType designe le type de l'element. SOAP-ENC:offset sert a designer la coordonnee de 
depart d'un vecteur transmis partiellement (voir plus loin). 

Puis vient la structure du vecteur : 

<xs:group name="Array"> 
<xs:sequence> 

<xs:any namespace="##any" minOccurs="0" 

maxOccurs=" unbounded" processContents="lax"/> 
</xs:sequence> 
</xs :group> 

suivie de la definition du type SOAP-ENC:Array et de l'accesseur anonyme : 

<xs:complexType name="Array"> 

<xs:group ref="tns:Array" minOccurs="0"/> 

<xs:attributeGroup ref="tns:arrayAttributes"/> 

<xs:attributeGroup ref="tns: common Attributes"/> 
</xs :complexType> 
<xs:element name="Array" type="tns:Array"/> 

SOAP-ENC : Array est done un vecteur dont les elements sont types uniformement par SOAP-ENC : ArrayType. 
II faut noter que l'inclusion de commonAttributes dans la definition du type SOAP-ENC:Array permet de 
mettre en ceuvre le mecanisme generalise de referencement SOAP 1.1. 
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Viennent enfin les attributs de 1' element du vecteur : 

<xs: attribute name=" posit ion" type="tns:arrayCoordinate"/> 
<xs:attributeGroup name=" a rrayMember Attributes'^ 

<xs: attribute ref="tns:position"/> 
</xs:attributeGroup> 

Exemples 

Voici un exemple de vecteur SOAP de quatre elements de type ens : bankcodeType (voir les exemples 
precedents) : 

<S0AP-ENC: Array S0AP-ENC:arrayType="ens:bankcodeType[4]"> 

<bankcode>4000K/bankcode> 

<bankcode>30002</bankcode> 

<bankcode>20003</bankcode> 

<bankcode>10004</bankcode> 
</SOAP-ENC:Array> 

La valeurde SOAP-ENC:arrayType specifle le type de l'element du vecteur SOAP ainsi que le nombre 
de dimensions et la taille (nombre d' elements) pour chaque dimension. La taille peut etre indeterminee, 
ce qui se traduit par deux crochets juxtaposes ([]). Le type de chaque element du vecteur peut etre de 
n'importe quel sous-type de SOAP- ENC:arrayType. Voici une representation alternative duRIB : 

<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4]"> 

<i tern xsi : type="ens : bankcodeType">4000K/i tem> 

<item xsi :type="ens:positioncodeType">00987</item> 

<item xsi :type="ens:accountcodeType">0000123456A</item> 

<item xsi :type="ens: control key Type">92</item> 
</SOAP-ENC:Array> 

Les elements des vecteurs SOAP 1.1 peuvent etre des structures ou d'autres valeurs composites : 

<S0AP-ENC: Array S0AP-ENC:arrayType="ens:RIBStructType[3]"> 
<ens:RIB> 

<bankcode>4000K/bankcode> 

<positioncode>00987</positioncode> 

<accountcode>0000123456A</accountcode> 

<control key>92</control key> 
</ens:RIB> 
<ens:RIB> 

<bankcode>4000K/bankcode> 

<positioncode>00987</positioncode> 

<accountcode>0000123654B</accountcode> 

<control key>18</control key> 
</ens:RIB> 
<ens:RIB> 

<bankcode>4000K/bankcode> 

<positioncode>00789</positioncode> 

<accountcode>0000456321C</accountcode> 

<control key>8K/control key> 
</ens:RIB> 
</SOAP-ENC:Array> 
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Vecteurs de vecteurs 

Les elements d'un vecteur SOAP peuvent etre d'autres vecteurs SOAP. Dans l'exemple ci-apres, un 
vecteur SOAP est compose de trois autres vecteurs SOAP, chacun de quatre elements de type 

SOAP-ENC:string : 

<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4][3]"> 
<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4]"> 

<item>vOeO</item> 

<item>vOel</item> 

<item>v0e2</item> 

<item>v0e3</item> 
</SOAP-ENC:Array> 
<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4]"> 

<item>vleO</item> 

<item>vlel</item> 

<item>vle2</item> 

<item>vle3</item> 
</SOAP-ENC:Array> 
<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4]"> 

<item>v2e0</item> 

<item>v2el</item> 

<item>v2e2</item> 

<item>v2e3</item> 
</SOAP-ENC:Array> 
</SOAP-ENC:Array> 

Vecteurs a plusieurs dimensions 

Les vecteurs SOAP 1.1 peuvent etre a plusieurs dimensions Voici un exemple d'un vecteur SOAP a 
deux dimensions de 3 * 4 elements de type SOAP-ENC : stri ng, concatenation du code banque et du code 
agence : 

<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[3.4]"> 

<item>10c0</item> 

<item>10cl</item> 

<item>10c2</item> 

<item>10c3</item> 

<item>llcO</item> 

<item>l lcl</item> 

<item>llc2</item> 

<item>l lc3</item> 

<item>12c0</item> 

<item>12cl</item> 

<item>12c2</item> 

<item>12c3</item> 
</SOAP-ENC:Array> 

Attention, un vecteur SOAP 1.1a deux dimensions de trois lignes pour quatre colonnes n'est pas la 
meme structure qu'un vecteur de trois vecteurs de quatre elements chacun ! 
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Partage des valeurs 

Le partage des valeurs dans les vecteurs SOAP suit la logique generate des valeurs plurireferencees : 

<S0AP-ENC: Array S0AP-ENC:arrayType="S0AP-ENC:string[4][3"> 

<S0AP-ENC: Array SOAP-ENC:arrayType="SOAP-ENC: string [4]" id="MyArray"> 

<ens:bankcodeType id="MyBankcode">4000K/ens:bankcodeType> 

<ens:positioncodeType id="MyPositioncode">00987</ens:positioncodeType> 

<ens:accountcodeType id="MyAccountcode">0000123456A</ens: account codeType> 

<ens: control key Type id=" My Control key">92</ens: control keyType> 
</SOAP-ENC:Array> 
<S0AP-ENC: Array SOAP-ENC:arrayType="SOAP-ENC: string [4] "> 

<ens:bankcodeType href="#MyBankcode"/> 

<ens:positioncodeType href="#MyPositioncodeV> 

<ens:accountcodeType>0000123654B</ens:accountcodeType> 

<ens: control keyType>18</ens: control keyType> 
</SOAP-ENC:Array> 

<S0AP-ENC: Array SOAP-ENC:arrayType="SOAP-ENC: string [4]" href="#MyArray"/> 
</SOAP-ENC:Array> 

Vecteurs types 

Nous sommes en mesure de declarer un type de vecteur et un accesseur anonyme dans notre schema 
applicatif ens : 

<xs : compl exType name="Array0f BankcodesType"> 
<xs:complexContent> 

<xs: restriction base=" SOAP- ENC:Ar ray "> 
<xs:sequence> 

<xs:element name="bankcode" 

type="tns:bankcodeType" max0ccurs=" unbounded "/> 
</xs:sequence> 
</xs: restrict!' on> 
</xs : compl exContent> 
</xs: compl exType> 
<xs : element name="ArrayOfBankcodes" type="tns: Array Of Ban kcodesType"/> 

Voici une occurrence conforme au schema ci-dessus : 

<ens:ArrayOfBankcodes SOAP-ENC:arrayType="ens :bankcodeType[4]"> 

<bankcode>4000K/bankcode> 

<bankcode>30002</bankcode> 

<bankcode>20003</bankcode> 

<bankcode>10004</bankcode> 
</ens:ArrayOfBankcodes> 

Vecteurs transmis partiellement 

Le style de codage SOAP permet seulement le codage d'une partie de vecteur. Seuls le troisieme et le 
quatrieme elements sont transmis par F element ci-apres : 

<S0AP-ENC: Array S0AP-ENC:arrayType="xsd:string[5]" S0AP-ENC:offset="[2]"> 

<i tem>troi si erne el ement</i tem> 

<item>quatrieme element</item> 
</S0AP-ENC:Array> 
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Vecteurs creux 



Voici un exemple de vecteur creux (un vecteur de quatre vecteurs a deux dimensions de taille indeter- 
minee) dans lequel sont transmis deux elements du troisieme vecteur : 

<S0AP-ENC: Array SOAP-ENC:arrayType="xsd:string[, ][4]"> 

<S0AP-ENC: Array SOAP-ENC : posi ti on=" [2] " SOAP-ENC:arrayType="xsd: string [10, 10] "> 
<item S0AP-ENC:position="[2,2]">troisieme ligne, troisieme colonne</item> 
<item S0AP-ENC:position="[7,2]">huitieme ligne, troisieme colonne</item> 
</S0AP-ENC:Array> 
</S0AP-ENC:Array> 



Evolutions SOAP 1.2 (draft) 

SOAP 1 .2 ne prend plus en charge des vecteurs creux ou transmis partiellement. 



Les pieces jointes 

Le probleme de la transmission avec des messages SOAP d'objets de toute sorte, tels que des GIF, 
TIFF, PDF, RTF, etc., voire des documents XML « entiers » (qui ne peuvent etre vehicules, en tant 
que tels, dans le message SOAP), des schemas XML, des DTD, etc., s'est pose pratiquement tout de 
suite apres la parution de la specification SOAP 1.1. 

La specification prevoit une methode permettant d'inclure tout objet dans le message SOAP, au prix 
d'un codage specifique en objet « opaque », comme une chaine de bits. Un objet opaque est encode 
comme une valeur de type S0AP-ENC:base64, ce dernier etant une restriction de xs:base64Binary, 
censee employer l'algorithme MIME (IETF - RFC2045) sans restriction de longueur de ligne : 

I<xs:simpleType name="base64"> 
<xs: restriction base="xs:base64Binary"/> 
</xs :simpleType> 

Par exemple : 

|<picture xsi :type="S0AP-ENC:base64"> 
aG93IG5vDyBicm73biBjb3cNCg== 
</picture> 

Cette methode a le merite d'exister, mais s'est rapidement revelee insuffisante, car penalisante en termes 
de performance : 

• les procedures d'encodage/decodage peuvent etre lourdes ; 

• la taille de l'objet code augmente de facon substantielle. 

Une premiere tentative de solution alternative au probleme de la transmission d'objets binaires s'est 
concretised par une note adressee au W3C le 1 1 decembre 2000 : SOAP Messages with Attachments 
(voir : http://www.w3.org/TR/SOAP-attachments). 
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La proposition repose sur deux choix, que Ton peut qualifier de minimalistes, car ils reutilisent largement 
des normes, standards et technologies existants : 

• l'approche « pieces jointes » dans laquelle les objets multimedias a transmettre apparaissent comme 
des pieces jointes (attachments) a un message SOAP ; 

• le mecanisme MIME (Multipurpose Internet Mail Extension) multipartie afin d'emboiter des 
documents composites, conjugue avec les schemas d'URI pour referencer les parties. 

La structure multipartie (Mul ti part/Rel ated), qui comprend le message SOAP et les pieces jointes, 
est appelee paquet SOAP. Elle ne peut etre identifiee comme une entite d'un type particulier car il n'y 
a aucun nom de type MIME qui permette de la designer et de Fidentifier en tant que telle. Un paquet 
SOAP est done une structure Multipart/Related generique (RFC2387) qui peut, evidemment, etre 
transportee par plusieurs protocoles Internet. 



References aux normes et standards utilises par SOAP Messages with Attachments 

- [RFC2387] The MIME Multipart/Related Content-type (http://www.ietf.org/rfc/rfc2387.txt) ; 

- [RFC2045] Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (http://www 
.ietf.org/rfc/rfc2045.txfj ; 

- [RFC21 11] Content-ID and Message-ID Uniform Resource Locators [http://www.ietf.org/rfc/rfc21 1 1.txt) ; 

- [RFC2396] Uniform Resource Identifiers (URI): Generic Syntax {http://www.ietf.org/rfc/rfc2396.txt) ; 

- [RFC2557] MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) {http://www.ietf.org/rfc/rfc2557.txf) ; 

- XML Base {http://www.w3.org/TR/xmlbase). 



Le paquet SOAP 

Un paquet SOAP est construit en utilisant le type de medium Multipart/ Related (RFC 2387). II 
contient un message SOAP 1.1 {message primaire) et d'autres entites additionnelles (les pieces jointes) 
qui sont correlees au message primaire de plusieurs facons. 

Le message primaire est emboite dans la ratine du corps de la structure Mul ti part/Rel ated. La valeur 
du parametre type du champ d'en-tete Multipart/ Related est text/xml, identique a la valeur du 
champ d'en-tete Content-Type du message SOAP 1.1 primaire. 

Les autres parties MIME sont etiquetees soit par un en-tete MIME Content-ID (structure en accord 
avec la RFC2045), soit par un en-tete MIME Content- Locati on (structure en accord avec la RFC2557). 

Le referencement, de l'interieur d'un message SOAP vers une piece jointe, peut etre effectue via 
l'attribut href, defini dans le style de codage SOAP 1.1, qui est de type xs : anyURI et est normalement 
utilise, en association avec l'attribut i d, pour mettre en ceuvre le mecanisme de referencement interne 
au message. 

Voici un exemple de paquet SOAP dans lequel le referencement est mis a contribution par 1' utilisation 
simple de Content- ID, et done d'URI de schema cid : 

MIME-Version: 1.0 

Content -Type: Multipart/Related; 

boundary="SOAP_Message_with_Attachments_boundary" ; 

type=text/xml ; 
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start="<LaDivinaCommedi a. xml@DanteAl ighieri .org>" 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/xml ; charset=UTF-8 

Content- ID: <LaDivinaCommedi a. xml@DanteAl ighieri .org> 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 

<DA: LaDivinaCommedia xmlns:DA="http://Opere.DanteAl ighieri .org/"> 
<DA: Inferno href="cid: Inferno. pdf@DanteAl ighieri .org"/> 
<DA: Purgatorio href ="cid:Purgatorio.pdf@DanteAl ighieri .org"/> 
<DA: Paradiso href ="cid:Paradi so. pdf@DanteAl ighieri .org"/> 

</DA: LaDi vinaCommedia> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/pdf 
Content-ID: <Inferno.pdf@DanteAl ighieri .org> 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/pdf 

Content-ID: <Purgatorio.pdf@DanteAl ighieri .org> 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/pdf 

Content- ID: <Paradi so. pdf@DanteAl ighieri .org> 



Libelles et references 

Le paquet SOAP presente la structure generate d'un Multipart/Related MIME. Dans ce cadre, 
regentee par les differentes PvFC de 1'IETF et independamment des technologies de services Web, la 
specification SOAP Messages with Attachments s'attaque au probleme particulier du referencement 
de l'interieur du message SOAP primaire vers les pieces jointes du paquet SOAP. 

Les ingredients du systeme de referencement des pieces jointes sont les libelles et les references. La 
specification SOAP Messages with Attachments precise comment : 

• calculer un libelle pour chaque piece jointe ; 

• mettre en ceuvre les references a chaque piece jointe ; 

• resoudre les references en libelles pour localiser les pieces jointes. 

Libelles des pieces jointes 

Chaque piece jointe est une partie MIME qui contient, soit un champ d'en-tete Content-ID, soit un 
champ d'en-tete Content- Location, soit les deux. 
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Un libelle d'une piece jointe est un URL II est possible d'attribuer a une piece jointe un ou deux libelles, 
qui suivent deux calculs d' attribution differents (mais non altematifs) : 

• le calcul utilisant la valeur du champ d'en-tete Content- 1 D ; 

• le calcul utilisant la valeur du champ d'en-tete Content- Location. 

Calcul de libelle utilisant la valeur du champ d'en-tete Content-ID 

La valeur du champ Content- 1 D est obtenue a partir d'un URI avec prefixe ci d, par une transformation 
syntaxique qui : 

• supprimele prefixe cid ; 

• opere la conversion des caracteres hex-escaped de type %hh aux equivalents ASCII ; 

• englobe le resultat par les caracteres < et >. 

A l'inverse, l'URI absolu cid:foo4ft25fool@bar.net est obtenu par transformation (inverse) de la 
valeur du champ d'en-tete : 

Content-ID: <foo«fool@bar.net> 

Le libelle d'une partie MIME peut done etre l'URI absolu obtenu par transformation a partir de la valeur 
de son champ d'en-tete Content- ID. 

Ce schema d' attribution est utilise dans l'exemple presente ci-apres : 

MIME-Version: 1.0 

Content-Type: Multipart/Rel ated;... 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml ; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xmlns: SOAP- E N V = " http://schemas.xml soap.org/soap/envelope/"> 

</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/pdf 

Content-ID: <Inferno.pdf@DanteAl ighieri .org> 

Le libelle de la piece avec champ d'en-tete : 
| Content-ID: <Inferno.pdf@DanteAl ighieri .org> 
est l'URI absolu cid:Inferno.pdf@DanteAl ighieri .org. 

Calcul de libelle utilisant la valeur du champ d'en-tete Content-Location 

La valeur du champ Content- Locati on est un URI. II peut etre, soit un URI absolu, soit un URI relatif. 

Un URI relatif implique l'existence d'un URI base, lequel est concatene a l'URI relatif pour obtenir 
un URI absolu. Le mecanisme d'obtention de l'URI absolu est uniforme et peut etre decrit comme : 

URI absolu = URI base + URI relatif 
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L'URI base pour le calcul du libelle de la piece jointe est soit : 

• l'URI absolu, valeurde l'en-tete Content-Location de l'entite Multipart/Related englobant ; 

• soit l'URI absolu par defaut, c'est-a-dire thismessage:/ (RFC2557). 

Libelle avec URI absolu dans Content-Location 

MIME-Version: 1.0 

Content-Type: Multipart/Related; ... 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xmlns: SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 

</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/pdf 

Content- Location: http: //Opere.DanteAl ighieri . org/ LaDivinaCommedi a/ I nferno.pdf 

Le libelle de la piece avec champ d'en-tete : 

Content- Location: http: //Opere.DanteAl ighieri .org/ LaDivinaCommedi a/ Inferno.pdf 
est l'URI absolu : 

http: //Opere.DanteAl ighieri .org/ LaDivinaCommedi a/ Inferno.pdf 
Calcul de libelle avec URI relatif (URI base dans l'entite englobant) 

MIME-Version: 1.0 

Content-Type: Mul tipart/Rel a ted;... 

Content- Location: http: //Opere.DanteAl ighieri .org/ LaDivinaCommedi a/ 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xmlns: SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 

</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/pdf 

Content- Location: Purgatorio.pdf 

Le libelle de la piece avec champ d'en-tete Content-Location: Purgatorio.pdf est l'URI absolu 

http: //Opere.DanteAl ighieri .org/ LaDivinaCommedi a /Purgatorio.pdf. 
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Calcul de libelle avec URI relatif (URI base par defaut) 

MIME-Version: 1.0 

Content-Type: Multipart/Related; ... 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml ; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xml ns: SOAP- ENV=" http://schernas.xml soap.org/soap/envelope/"> 

</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/pdf 
Content-Location: Paradiso.pdf 

Le libelle de la piece avec champ d'en-tete Content-Location: Paradiso.pdf est l'URI absolu 
thismes sage: /Pa radiso.pdf. 

References aux pieces jointes 

Les references aux pieces jointes, de Finterieur du message SOAP, sont mises en ceuvre par F utilisation 
de l'attribut href, propre au mecanisme general de referencement du style de codage SOAP 1.1. Son 
usage est etendu par la specification SOAP Messages with Attachments a la gestion des pieces jointes 
pour referencer les parties MIME du paquet SOAP. 

Le processus de resolution des references, a savoir de localisation de la piece jointe referencee, 
prevoit done trois etapes : 

1. le calcul des libelles ; 

2. le calcul de la reference (RFC2396) ; 

3. la resolution de la reference par appariement avec les libelles. 

Lorsque la valeur de href est un URI absolu, la deuxieme etape est deja accomplie. Lorsque la valeur 
de href est un URI relatif, il est necessaire d'obtenir un URI base pour pouvoir calculer un URI 
absolu. La deuxieme etape, si elle a lieu, est done une etape de calcul d'URI absolu. 

La troisieme etape permet de trouver, par appariement de la reference avec les libelles des pieces 
jointes, la piece jointe referencee. Elle sera analysee apres exposition du mecanisme de calcul de la 
reference. 



Resolution des references 

Ce processus de resolution des references est une copie du mecanisme introduit dans la RFC2557 pour les 
messages multiparties MIME, qui ont comme racine un document de type MIME text/html , et sont utilises pour 
vehiculer des pages HTML avec des documents rattaches en pieces jointes. 
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La RFC2396 definit un processus general de calcul de FURI absolu. La note SOAP Messages with 
Attachments specifie comment ce processus general s'applique aux messages SOAP avec pieces jointes. 
La premiere etape du calcul de FURI absolu est la recherche de l'URI base : 

1. II faut chercher d'abord les declarations de d'URI base dans le message SOAP lui-meme. 
Ces declarations sont specifiees au moyen de l'attribut reserve xml :base. Laportee des decla- 
rations de xml : base, ainsi que la concatenation des URI pour obtenir un URI base absolu suit 
la regie usuelle XML Base. 

2. S'il n'y a pas de declaration dans le message SOAP, il faut chercher la valeur de l'en-tete 
Content-Location, d'abord dans la partie racine (qui englobe immediatement le message 
primaire SOAP) de la structure multipartie MIME, et ensuite dans la structure Multipart/ 
Related. 

3. S'il n'y a toujours pas d'URI base trouve, celui-ci est etabli par defaut a thismessage:/ 
(RFC2557). 

Reference avec URI absolu dans href 

MIME-Version: 1.0 

Content-Type: Mul tipart/Rel ated;... 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml ; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 

<DA: LaDivinaCommedia xmlns:DA="http://Opere.DanteAl ighieri .org/"> 
<DA: Inferno 

href="cid: Inferno. pdf@DanteAl ighieri .org"/> 
<DA:Purgatorio 
href ="http://Opere.DanteAl ighieri .org/LaDivinaCommedia/Purgatorio.pdf"/> 

</DA: LaDivinaCommedia> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
--SOAP_Message_with_Attachments_boundary 

Dans l'exemple, nous presentons deux URI absolus (de schemas differents), valeurs de href. Ces 
deux URI sont des references aux pieces jointes. 

Calcul de reference avec URI relatif via l'URI base dans le message 

MIME-Version: 1.0 

Content-Type: Mul tipart/Rel ated;... 

--SOAP_Message_with_Attachments_boundary 
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Content-Type: text/xml ; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 

<DA: LaDivinaCommedia xml ns:DA="http://Opere.DanteAl ighieri .org/" 
xml :base="http://Opere.DanteAlighieri .org/LaDivinaCommedia/"> 
<DA: Inferno href="Inferno.pdf"/> 

</DA:LaDi vinaCommedia> 

</SOAP-ENV:Body> 

</SOAP-ENV:Envelope> 

--SOAP_Message_with_Attachments_boundary 

La reference calculee apartirde href=" Inferno.pdf" et de 

xml :base="http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/" 
est FURI absolu : 

http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/ Inferno.pdf 

Calcul de reference avec URI relatif via I'URI base dans I'entite immediatement englobante 

MIME-Version: 1.0 

Content-Type: Multipart/Rel ated;... 

--SOAP_Message_with_Attachments_boundary 

Content-Type: text/xml; charset=UTF-8 

Content-ID: <LaDivinaCommedi a. xml@DanteAl ighieri .org> 

Content- Location: http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/ 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xml ns: SOAP- E N V = " http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 

<DA: LaDivinaCommedia xml ns:DA="http://Opere.DanteAl ighieri .org/"> 

<DA:Purgatorio href="Purgatorio.pdf"/> 

</DA:LaDi vinaCommedia> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
--SOAP_Message_with_Attachments_boundary 
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La reference calculee a partir de href="Purgatorio.pdf " et de 

Content- Location: http://Opere.DanteAl ighieri .org/LaDivinaCommedia/ 

est l'URI absolu : 

http://Opere.DanteAlighieri.org/LaDivinaCommedia/Purgatorio.pdf 

Calcul de reference avec URI relatif via l'URI base dans I'entite Multipart/Related 

MIME-Version: 1.0 

Content-Type: Mul tipart/Rel a ted;... 

Content- Location: http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/ 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml ; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 

<DA: LaDivinaCommedia xmlns:DA="http://Opere.DanteAl ighieri .org/ "> 

<DA: Purgatorio href="Purgatorio.pdf"/> 

</DA: LaDivinaCommedia> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
--SOAP_Message_with_Attachments_boundary 

La reference calculee a partir de href="Purgatorio.pdf " et de 

Content- Location: http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/ 
est l'URI absolu : 

http://Opere.DanteAl ighieri .org/ LaDivinaCommedia/ Purgatorio.pdf 

Calcul de reference avec URI relatif via l'URI base par defaut 

MIME-Version: 1.0 

Content-Type: Mul tipart/Rel a ted;... 

--SOAP_Message_with_Attachments_boundary 
Content-Type: text/xml; charset=UTF-8 

<?xml version="1.0" encoding="UTF-8"?> 
<S0AP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap.org/soap/envelope/"> 

<SOAP-ENV:Body> 
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<DA: LaDi vinaCommedia xmlns:DA="http://Opere.DanteAl ighieri .org/opere"> 

<DA:Paradiso href="Paradiso.pdf"/> 

</ DA: LaDi vinaCommedia> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
--SOAP_Message_with_Attachments_boundary 

La reference calculee apartirde href=" Pa radiso.pdf" est FURI absolu thismessage:/ Pa radiso.pdf. 

Resolution des references 

La resolution d'une reference est le processus de localisation de la piece jointe referencee par 
appariement de la reference avec chaque libelle. 



MIME- Version: 1.0 

Content-Type: Multipart /Related; - 

Content -Location; attp://Opere*DaDteAlichieri.ora/LADiviAAC<ifiiiiiedi*/ riffc 

— SOAP_Message_wi th_Attachments_boundary 
Content -Type: text/xml; charset=UTF-a 

<lxmX version="l .0" encoding="UTF-8"?> 

<SOAP-ENV: Envelope xrnlns : $QAP-ENV="http: //schemas .xmlsoap.org/soap/envelope/"> 
<SOAP-ENV:Body> 

<DA: LaDi vinaCommedia xmlns: DA= n http://Opere.DanteAlighieri.org/"> 
<DA: Inferno href B B in£Arao.pdf ■/> f^ 

<DA: Purgatorio nref="http; //opare, DenteAlinhieri. org /LaDi vinaCoonEodia/Pura«torio.s>cl£-/> A 
<DA:Paradiso hT-8t-"cid: Paradise. pdf enanteAJ.ighieri.ors"/> Q 

</DA: LaDivinaComjnedia> 

</SGAP-ENV:Body> 

</SOAP- ENV : £nvelope> 

— SOAP_Message_witri_Attachments_boun.dary 

Content-Type: text/pdf 

Content- Location: btcp://Ooars.DantaUianieri.org/LaI>iTinaComedia/ Infsrno.pdf (j^ 

— S0AP_Message_with_AttachTnent5_boundary 

Content-Type; text/pdf 

content -Location: Purgatorio.pdf |>| 

— £0A P_Me s s a ge_w i t h_A 1 1 a chme n t s_bo unda ry 

Con tent -Type: text/pdf 

Content-ID: Paradiso.pdf&D&nt eAlichieri.org Gk 



Figure 8-1 

Exemple de referencement des pieces jointes a partir du message SOAP. 
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La specification SOAP Messages with Attachments ne donne pas d' indications ulterieures sur le 
processus, excepte : 

• si aucun libelle ne correspond a la reference, les regies de resolution standards rattachees aux 
schemas des URI s'appliquent a la reference irresolue ; 

• si deux ou plusieurs pieces jointes exhibent le meme libelle, les regies de resolution de conflit de 
la RFC2557 s'appliquent. 

L'appariement des URI (reference et libelle) suit les regies usuelles de la RFC2396, et est normalement 
dependant des schemas des URI a comparer. Notamment, un identifiant de host comme http : //Opere 
.DanteAlighieri .org n' est pas sensible alacasse (s'apparie avec http: //opere. dantealighieri .org). 

L'exemple illustre figure 8-1 presente quelques-unes des differentes possibilites d' attribution de libelles 
et de referencement des pieces jointes : 

La valeurde Content- Location de la structure multi-partie O sert d'URIbase. 

La reference © developpee est http: //Opere. DanteAlighieri . org/ LaDivinaCommedi a/ Inferno .pdf, 
elle est obtenue a partir de la valeur de h ref (URI relatif) et de FURI base O. Sa resolution localise la 
piece jointe au libelle ©. 

La reference © developpee est http://Opere.DanteAlighieri.org/LaDivinaCommedia/Purgatorio 
.pdf, valeur de href. Sa resolution localise la piece jointe de libelle ©. 

La reference ©est cid:Paradiso.pdf@DanteAlighieri .org, valeurde href. Sa resolution localise la 
piece jointe de libelle 0. 

Le libelle © est http://Opere. DanteAlighieri .org/LaDivinaCommedia/Inferno.pdf, valeurde Content- 
Location. 

Le libelle© est http://Opere.DanteAlighieri.org/LaDivinaCommedia/Purgatorio.pdf, obtenu a 
partir de la valeur de Content- Location et de FURI Base O de la structure multipartie. 

Le libelle est cid:Paradiso.pdf@DanteAlighieri .org obtenu par transformation de la valeur de 

Content-ID. 



Conclusion 

Nous avons presente la problematique du codage des donnees atomiques et des structures de donnees 
manipulees par les langages de programmation dans les messages SOAR ainsi que le style de codage 
SOAP 1.1. 

Les outils de codage des donnees dans les messages SOAP jouent un role important, notamment pour 
diminuer F effort de transformation des applications patrimoniales en services Web. 

Les mecanismes de codage sont complexes a manier et dans la realite engendent des problemes 
d'interoperabilite entre applications qui utilisent des implementations heterogenes de SOAP 1.1. Le 
document WS-I Basic Profile Version 1.0- (Working Group Draft - Date: 2002/10/08) pose des limi- 
tations importantes, pour cause d'interoperabilite, a Fusage de la representation codee. Ces limitations, 
jugees excessivement draconiennes par plusieurs specialistes, interdisent pratiquement Fusage de la 
representation codee SOAP et garantissent seulement Finteroperabilite des representations litterales. 
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RecommandationsWS-l Basic Profile 1.0 (draft) 

-R1005 : un message ne doit contenir d'attributs SOAP-ENV:encodingStyle dans aucun des elements qui 
appartiennent au vocabulaire http://schernas.xmlsoap.org/soap/envelope (et done dans aucun des 
elements enveloppe, corps, en-tete, erreur). 

-R1006, R1007: en outre, un message ne doit contenir d'attributs SOAP-ENV:encodingStyle dans aucun 
descendant direct ou indirect de I'element corps (SOAP- ENV : Body). 



Evolutions SOAP 1.2 (draft) 

L'URI http://www.w3.org/2002/06/soap-encoding designe le style de codage SOAP 1.2 (working draft a la 
date de redaction de cet ouvrage) ainsi que le schema de codage et le vocabulaire XML associe (prefixe enc). 
Par ailleurs, le support du style de codage SOAP 1 .2 est optionnel (ce n'est pas un critere de conformite avec les 
specifications). 



En fait, la representation codee SOAP 1.1 peut etre appliquee dans les echanges entre applications 
mises en ceuvre sur des implementations SOAP 1 . 1 largement utilisees comme celles de Microsoft et 
d'IBM. 

Si Ton regarde la problematique de plus pres et si Ton accepte l'usage systematique de XML 
Schema, la distinction litteral/code a deux justifications : 

• le fait que XML Schema est arrive a l'etat de recommandation apres SOAP 1.1 ; 

• le fait que XML Schema ne permet pas nativement de definir des graphes et d'autres structures 
interessantes pour les langages de programmation (ex. : les hash tables). 

Les auteurs de la specification SOAP ont ete obliges de definir un modele abstrait de donnees SOAP 1.1, 
independamment de Futilisation d'un schema XML Schema, parce qu'ils n'avaient pas d'autres 
moyens d' assurer un codage efficace de certaines donnees atomiques et structurees manipulees par 
les langages de programmation. 

XML est en train de devenir le format universel des donnees, et XML Schema le formalisme universel 
de description de ces donnees. Confier a un document XML des vecteurs, des graphes et d'autres 
structures de donnees est un besoin qui va au-dela de la construction et de F interpretation des messages 
SOAP, et qui devrait etre pris en compte nativement par la specification XML Schema. 
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Echanger avec un service - 
Liaison et styles d'echange 



Une liaison (binding) generique SOAP est un ensemble de consignes destinees a mettre en ceuvre le 
mecanisme SOAP sur un protocole reseau specifique. La specification SOAP 1 . 1 precise la liaison 
avec le protocole HTTP (liaison SOAP/HTTP). 

SOAP perniet de mettre en ceuvre plusieurs styles d'echange (voir figure 9-1) : 

• Message a sens unique (one-way) : il correspond a F envoi unidirectionnel d'un message SOAP. 
C'est le style d'echange de base. 

• Requete/reponse : ici, l'envoi d'un message de requete est suivi d'un message de reponse correle. 
Ce style est en fait defini implicitement (via la liaison generique SOAP/HTTP). Le style requete/ 
reponse s' applique notamment a la mise en ceuvre de Yappel de procedure distante (RPC : Remote 
Procedure Call), pour lequel SOAP 1 . 1 definit une representation specifique. Le style document est 
aussi defini implicitement comme le complement du RPC : il designe les requetes/reponses au 
format standard SOAP qui ne sont pas une representation explicite de l'appel de procedure distante. 

Nous avons presente le style message a sens unique comme le style de base dans le chapitre 7. Dans 
ce chapitre, nous allons exposer les implications de l'utilisation de ce style, ainsi que celles liees a 
l'utilisation du style requete/reponse, dans le cadre de la liaison SOAP/HTTP II s'agit d'un choix 
structurant car le protocole HTTP est bidirectionnel (par opposition a un protocole comme UDP, qui 
est unidirectionnel). 

Nous presentons les styles d'echange SOAP directement et concretement sur la liaison SOAP/HTTP 
pour deux raisons majeures : 

• le protocole HTTP est sans aucun doute le plus utilise, dans les applications pratiques, pour vehiculer 
les messages SOAP ; 

• la liaison SOAP/HTTP est la seule preconisee, pour cause d'interoperabilite, par le consortium WS-I. 
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Par ailleurs, nous allons etudier le style RPC (Remote Procedure Call), dont la representation est deflnie 
explicitement par la specification SOAP 1.1. 



Styles 


Message 
a sens unique 




SOAP 


Requete 
reponse 


Document 

RPC 



Figure 9-1 

Taxinomie des styles d'echange SOAP 1.1. 



La liaison SOAP/HTTP 

Du point de vue de la definition stricte d'une liaison, SOAP/HTTP est une liaison generique, car elle 
admet, pour le protocole HTTP, plusieurs formats et codages de donnees. HTTP est un protocole 
bidirectionnel synchrone, forme par le couple indissociable requete/reponse HTTP (voir figure 9-2). 
Du point de vue de SOAP, il joue done le role d'un protocole de transport capable de gerer automati- 
quement la correlation entre les deux messages contenus respectivement dans le corps de la requete 
et le corps de la reponse HTTP. 

La mise en ceuvre des styles d'echange SOAP pourrait etre effectuee avec plusieurs methodes HTTP. La 
liaison standard SOAP/HTTP, definie dans la specification SOAP 1.1, stipule que la seule methode 
possible est HTTP POST (sauf en cas d'utilisation du HTTP Extension Framework - IETF - RFC2774). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

SOAP 1.1 definit une seule liaison generique SOAP : la liaison SOAP/HTTP. Le profil de base WS-I exige done 

I'usage de HTTP (obligatoire) et indique que les messages devraient etre envoyes au moyen de la version 1.1 du 

protocole (R1 140). 

En revanche, le profil de base WS-I interdit I'utilisation du HTTP Extension Framework (RFC2774) qui est permise 

par la specification SOAP 1.1 (R1108). 

Les recommandations du profil de base permettent I'utilisation pour I'echange de messages du port TCP 80, mais 

ne le rendent pas obligatoire (R1 110). 

Le mecanisme des cookies HTTP (RFC2965), utilise pour la gestion des sessions, est permis dans la liaison 

SOAP/HTTP (R1 120), mais il faut savoir qu'un serveur HTTP ne peut pas exiger la gestion des cookies de la part 

du client (R1 121) et doit done etre organise en consequence. La conformite avec la RFC2965 est recommandee 

(R1122). 



Echanger avec un service - Liaison et styles d'echange 

Chapitre 9 



Evolutions SOAP 1.2 (draft) 

SOAP 1.2 interdit I'utilisation du HTTP Extension Framework (RFC2774), qui est permise en SOAP 1.1, bien que 
deconseillee par le profil de base WS-I. Nous ne detaillerons done pas I'utilisation du HTTP Extension Framework 
dans cet ouvrage. 

SOAP 1 .2 etend, pour certains usages, la liaison SOAP/HTTP a la methode HTTP GET. Par exemple, dans le cas 
d'interrogations idempotentes et sans effets de bord, ou llnterrogation peut etre entierement identifier par I'URI 
cible de la requete, cet usage, considere Web friendly, est recommande. 
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En-tete HTTP 



Status HTTP 



Corps HTTP 




Figure 9-2 

Requete/reponse HTTP (sans transfert par tranches). 



HTTP 1.1 et transfert en pipe-line 

HTTP/1.1 permet la persistance de la connexion et le transfert en pipe-line, e'est-a-dire l'acheminement en 

sequence (pipelining) des requetes, done une forme d'asynchronisme (voir le chapitre 5). Sur une connexion 

persistante (par defaut), il est possible d'envoyer des requetes en sequence sans attendre les reponses respectives. 

Le serveur HTTP doit envoyer les reponses sans trous et dans le meme ordre. 

L'utilite de la connexion persistante se mesure surtout en termes de performance : I'ouverture/fermeture de la 

connexion est une operation couteuse qu'il est avantageux de mutualiser. 

La faisabilite et l'utilite de I'emploi du pipelining avec SOAP ne sont pas clairement etablies a ce jour. En tout 

etat de cause, le pipelining ne pourrait s'appliquer qu'a des requetes « paralleles » du point de vue applicatif, 

independantes entre elles en termes de changements d'etat et d'effets de bord induits. 
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HTTP 1.1 et transfert par tranches 

La fonction de codage pour le transfert par tranches (chunked transfer coding) de HTTP permet d'envoyer par tranches 
successives des messages de taille indeterminee a remission. Cette fonction est theoriquement utilisable avec 
SOAP 1.1. 



Le message a sens unique SOAP sur HTTP 

II est possible de mettre en ceuvre sur HTTP le style d'echange message a sens unique, qui repose sur 
le transmission simple d'un message SOAP via la requete HTTP (voir figure 9-3). La reponse a la 
requete HTTP vehiculant un message a sens unique, en dehors des situations d'erreur, presente un 
corps HTTP vide de messages SOAP et le contenu de F en-tete HTTP (code HTTP, autres champs, etc.) 
transporte les informations usuelles de type « compte rendu » de reception (un accuse de reception en 
cas de reussite). 



Requete HTTP 



En-tete HTTP 
[POST 




Corps HTTP - Message one- way - Enveloppe SOAP 
TErMeVsOAP 



Corps SOAP 



Reponse HTTP 



En-tete HTTP 
1 202 Accepted 




Figure 9-3 

Message a sens unique SOAP sur HTTP (avec accuse de reception HTTP). 



La requete/reponse SOAP sur HTTP 

La liaison SOAP/HTTP s'adapte naturellement au style d'echange de type requete/reponse, qu'il soit 
RPC ou document (les styles RPC et document sont presentes en detail plus loin dans ce chapitre). La 
requete et la reponse SOAP sont enchassees respectivement dans la requete et la reponse HTTP (voir 
figure 9-4). 



Echanger avec un service - Liaison et styles d'echange 

Chapitre 9 



Requete HTTP 




En-tete HTTP 



POST 



Corps HTTP = Requete SOAP = Enveloppe SOAP 


En-tete SOAP 

L_ _j 


Corps SOAP 







Reponse HTTP 



En-tete HTTP 



200 OK 



Corps HTTP = Reponse SOAP = Enveloppe SOAP 


En-tete SOAP 

L_ 


Corps SOAP 








Figure 9-4 

Requete/reponse SOAP (RPC ou document) sur HTTP. 



Le message d'erreur SOAP sur HTTP 

La liaison SOAP/HTTP s'adapte naturellement a la gestion de la correlation entre le message en 
erreur SOAP (faulty message), que celui-ci soit un message a sens unique ou une requete, et le 
message d'erreur SOAP (fault message). Nous rappelons qu'un message en erreur SOAP n'est pas 
forcement un message syntaxiquement ou semantiquement incorrect, mais simplement un message 
dont le processus de reception/consommation rencontre une situation d'erreur. De meme, la specifi- 
cation SOAP attache a juste titre une importance primordiale a la correlation entre message en erreur 
et message d'erreur, quelle que soit la cause de l'erreur. 

L'avantage de l'utilisation de HTTP pour le style message a sens unique est qu'il est possible, dans 
les situations d'erreur SOAP, d'inclure dans la reponse HTTP le message d'erreur SOAP et done de 
mettre en ceuvre via HTTP la correlation directe avec le message en erreur (voir figure 9-5). 
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Figure 9-5 

Correlation message SOAP en erreur/message d'erreur SOAP via la liaison SOAP/HTTP. 

Nous verrons par la suite que : 

• cette approche suppose une forme de synchronisme entre la « consommation » du message et F envoi 
de la reponse HTTP ; 

• il est deconseille, pour cause d'interoperabilite par le WS-I, d'inclure un message d'erreur SOAP 
dans la reponse HTTP d'une requete qui transporte un message a sens unique. 

Dans le style d'echange requete/reponse (RPC ou document), lorsque la requete SOAP est en erreur, 
la reponse HTTP heberge naturellement le message d'erreur SOAP correspondant (voir figure 9-5). 



La requete HTTP pour SOAP 

SOAP introduit dans HTTP un nouveau champ d'en-tete (SOAPAction) et impose la valeur text/xml 
pour le champ Content-Type. 
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Le champ SOAPAction 

SOAP introduit dans Fen-tete HTTP POST le nouveau champ de requete SOAPAction, pour indiquer 
le but (intent) du message SOAP. La specification SOAP 1.1 precise que ce champ doit etre present 
dans une requete HTTP vehiculant un message SOAP. 

Le champ SOAPAction : 

• soit contient un URI (qui peut etre aussi une chaine de caracteres vide) ; 

• soit ne contient aucune valeur (mais le champ est present quand meme). 

En voici des exemples : 

1. Une valeur d'URI differente de la chaine vide designe le but de la requete HTTP SOAP. En fait, 
cet URI peut etre utilise par un serveur HTTP proxy ou une passerelle pour filtrer ou acheminer 
le message vers F application concernee. 



I 



SOAPActi on : "HTTP : //exampl e . org/account#open" 
SOAPActi on : "org . exampl e . account .jar" 



2. La valeur chaine vide "" designe comme « but » de la requete HTTP SOAP FURI cible de la 
requete HTTP. 

| SOAPAction: "" 

3. L'absence de valeur du champ SOAPAction signifie que le message ne transporte pas d'indication 
du but de la requete HTTP SOAP. En realite, la presence de ce champ vide dans une requete 
HTTP SOAP permet d'identifier la requete HTTP comme un moyen de transport d'un message 
SOAP sans etre oblige d'analyser le contenu du corps de la requete. Lidee d'origine est de faci- 
liter le travail d'acheminement et de filtrage de la part des serveurs HTTP, proxies et passerelles. 
Lutilisation de ce champ en SOAP 1.1 a provoque des problemes d'interoperabilite (voir le 
chapitre 17 « Le defi de Finteroperabilite ») qui sont resolus aujourd'hui. Ce champ disparait en 
SOAP 1.2, remplace par une nouvelle consigne d'utilisation du champ Content-Type. 



Recommandations WS-I Basic Profile 1.0 (draft) 

Une recommandation du profil de base WS-I confirme qu'il est possible de placer comme valeur du champ SOAPActi on 
une chaine de caracteres quelconque, y compris la chaine vide (R1 1 09). En effet, llnformation pertinente sur le but 
du message est contenue dans I'enveloppe SOAP. 



Evolutions SOAP 1.2 (draft) 

L'en-tete SOAPAction a ete supprime dans la liaison SOAP 1.2/HTTP. Par ailleurs, un nouveau code, 427, a ete 
reserve (IANA) pour indiquer que le champ est exige par le serveur HTTP, [.'emission du nouveau code est a la 
discretion du serveur HTTP. A la place de SOAPAction, et avec la meme semantique, SOAP 1.2 utilise I'attribut 
acti on du type MIME appl i cati on/soap+xml , qu'il faut obligatoirement utiliser comme valeur de Content-Type, 
a la place de text/xml (voir la section suivante). 
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Le champ Content-Type 

La valeur du champ de l'en-tete HTTP Content-Type (de type « entite », voir chapitre 5), qui renseigne 
sur le type MIME de F entite transportee, doit etre obligatoirement text/xml , pour un message SOAP. 
A cette valeur suit une valeur de Fattribut char set : 

Content-Type: text/xml; charset="utf-8" 



Evolutions SOAP 1.2 (draft) 

SOAP 1.2 utilise le type MIME application/soap+xml a la place de text/xml comme valeur de Content- 
Type. L'enregistrement du nouveau type de medium est en cours aupres de NETF. 

Par ailleurs, le nouveau type application/soap+xml prend en charge I'attribut action qui est utilise avec la 
meme semantique que SOAPActi on en SOAP 1 .1 . 

En conclusion, une requete ou response HTTP transportant un message SOAP est detectee, sans que soit necessaire 
d'analyser le contenu de son corps, via le type MIME de son contenu. Le but [intent} du message est la valeur (un 
(JRI)de I'attribut action de la valeur application/soap+xml du champ « entite » Content-Type. 



La reponse HTTP pour SOAP 

La reponse HTTP vehicule les codes de retour HTTP. Dans la liaison SOAP/HTTP, les codes 2xx 
indiquent que le message SOAP a ete recu. En revanche, le code ne donne pas a priori d' information 
explicite sur Tissue de la consommation (analyse, evaluation, traitement) du message SOAP. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Si le contenu de la requete HTTP est mal forme (c'est-a-dire contient un document XML mal forme qui ne peut pas 
etre analyse), la reponse HTTP devrait afficher le code HTTP 400 Bad Request (R1113). 
Si la methode de la requete HTTP n'est pas POST, la reponse HTTP devra/r afficher le code 405 Method not 
Allowed (R1114). 

Si la valeur de Content-Type de la requete HTTP n'est pas text/xml , alors la reponse HTTP devrait afficher le 
code 415 Unsupported Media Type (R1 115). 

Les trois codes listes manifestent des erreurs de reception du message SOAP : le message SOAP n'a pas ete 
regu, done n'a pas ete consomme et ne pourra pas I'etre. 

Une reponse HTTP qui signale une erreur ou une defaillance differente de celles listees doit presenter le code 500 
Internal Server Error (R1106). 

Par ailleurs, un message SOAP qui contient seulement un element SOAP- ENV: Fault doit etre interprete comme 
un message d'erreur (R1 107). Si le contenu de la reponse HTTP est un message d'erreur SOAP, la valeur du code 
HTTP devrait etre 500 Internal Server Error (R1116). La recommandation d'interoperabilite relache le 
niveau d'obligation de la specification SOAP 1.1. 

La recommandation du WS-I est que les implementations devraient examiner systematiquement I'enveloppe SOAP au 
lieu de se contenter d'examiner le code HTTP, car ce dernier pourrait etre change par I'infrastructure de communication 
du reseau. En pratique, il est recommande d'utiliser systematiquement le code 500 dans une reponse qui transporte 
un message d'erreur SOAP. Le code 500 manifeste done soit une defaillance du serveur soit un erreur de consom- 
mation du message SOAP (le message a ete regu et sa consommation a ete interrompue par la levee d'une erreur). 

Si le serveur HTTP redirige la requete vers un autre noeud, le profil de base WS-I recommande d'utiliser le code 
HTTP 307 Temporary Redirect (R1130). 
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Evolutions SOAP 1.2 (draft) 

Le draft SOAP 1 .2 fournit une description plus fine de I'utilisation des codes HTTP de type 2xx, 3xx, 4xx. 



En cas d'erreur dans le processus de consommation, le serveur HTTP doit retourner le code 500 
Internal Server Error. La reponse HTTP doit inclure un message SOAP qui doit contenir un element 
erreur comme descendant direct du corps SOAP. Nous allons constater par la suite que cette exigence 
ne peut etre satisfaite que si la consommation du message SOAP est entierement synchrone avec la 
requete/reponse HTTP. 

La reponse HTTP correlee a un message a sens unique SOAP 

La reponse HTTP a une requete HTTP qui achemine un message a sens unique SOAP qui a ete recu 
et, eventuellement, consomme sans levee d'erreur SOAP, porte un code HTTP de type 2xx et contient 
un corps HTTP vide. 

La reponse HTTP a une requete HTTP vehiculant un message a sens unique SOAP en erreur affiche 
le code 500 Internal Server Error etdevrait, selon la specification, transporter un message d'erreur 
SOAP dans le corps HTTP. La correlation entre message a sens unique en erreur et message d'erreur est 
realisee par la correlation requete HTTP/reponse HTTP. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

La reponse HTTP a la requete qui contient un message a sens unique SOAP devrait afficher le code 202 Accepted 
si aucune erreur ou defaillance n'est detectee avant I'envoi de la reponse (R1 112). 

Pour les messages a sens unique mis en oeuvre su la liaison HTTP, le profil de base interdit, pour cause d'inter- 
operabilite, d'inclure dans la reponse HTTP un message SOAP (R2714). Cette interdiction ne permet done pas 
d'utiliser la reponse HTTP pour vehiculer un message d'erreur SOAP correle au message a sens unique en erreur 
contenu dans la requete. 



La reponse HTTP correlee a une requete SOAP 

La reponse HTTP correlee a une requete SOAP recue, eventuellement analysee, evaluee et traitee avec 
succes, presente un code HTTP de type 2xx et heberge dans le corps HTTP la reponse SOAP. 

La reponse HTTP a une requete SOAP en erreur (erreur syntaxique, erreur semantique, defaillance 
du consommateur) presente le code HTTP 500 Internal Server Error et transporte dans le corps HTTP 
un message d'erreur SOAP. La correlation entre requete SOAP en erreur et message d'erreur est 
realisee par la correlation requete HTTP/reponse HTTP. 
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La reponse HTTP a la requete qui vehicule une requete SOAP ctewa/f afficher le code 200 OK si aucune erreur ou 
defaillance n'est detectee avant I'envoi de la reponse (R1 111). 
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La consommation du message et la gestion des erreurs 

Au niveau fonctionnel, le message SOAP vehicule un acte de communication qui est soumis a des 
conditions de succes et a des conditions de satisfaction (voir chapitre 2). 

Les conditions de succes sont posees sur la syntaxe et la semantique du message. Elles sont remplies 
si le message est : 

• syntaxiquement correct ; 

• emis par un agent logiciel ayant la capacite, le droit et l'autorisation de le produire et de Femettre 
(d'accomplir Facte de communication) ; 

• recu par un agent logiciel ayant les capacites d' analyse, d' evaluation et de traitement du message 
(d'accueillir Facte de communication) ; 

• transmis dans un contexte et un environnement dans lesquels Facte de communication est correct 
et pertinent. 
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ou defaillance 
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Message 
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Figure 9-6 

Sequence de taches de consommation d'un message SOAP. 
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Un acte de communication ayant rempli toutes ses conditions de succes est dit reussi, sinon il est dit 
manque. Un acte de communication reussi est cense operer un effet pragmatique chez la cible de 
Facte, a savoir provoquer les calculs demandes, les transitions d'etat attendues et declencher les 
actions prevues (effets de bord). Les conditions de satisfaction de Facte de communication sont 
remplies lorsque les calculs, les transitions d'etat et les actions sont accomplies avec succes. Un acte 
de communication qui a rempli toutes ses conditions de satisfaction est dit acheve, sinon il est dit 
inacheve. Un acte acheve est certainement reussi, alors qu'un acte reussi peut rester inacheve. 

L' effet pragmatique de Facte de communication est mis en ceuvre par l'agent logiciel cible au moyen 
d'un traitement declenche par la reception d'un message syntaxiquement et semantiquement correct. 
Nous appelons consommation d'un message SOAP (ou d'une de ses parties), l'activite effectuee par 
l'agent logiciel destinataire du message suite a la reception du message (voir figure 9-6). La specifi- 
cation SOAP precise que la consommation du corps du message est a la charge du destinataire (le 
recepteur ultime), alors que la consommation des entrees de l'en-tete peut etre a la charge des inter- 
mediaries (voir chapitre 7). Le developpement qui suit fait reference a la consommation du corps du 
message, mais peut etre facilement transpose a la consommation des entrees de l'en-tete. 

L'activite de consommation se decompose idealement en trois taches : 

• Y analyse syntaxique du message (controle syntaxique) ; 

• V evaluation semantique du message (controle semantique) ; 

• le traitement, qui produit les calculs, les transitions d'etat et les effets de bord declenches par la 
reception reussie d'un message syntaxiquement et semantiquement correct. 

Un acte de communication vehicule par un message est reussi si les taches d' analyse et d' evaluation 
se terminent avec succes. II est acheve apres terminaison avec succes du traitement. 

Les trois taches listees s'appliquent aussi bien au message a sens unique qu'a la requete/reponse. 
L implementation de ce dernier style d'echange demande systematiquement la mise en ceuvre d'un 
effet de bord particulier : la production et Y emission de la reponse SOAP (voir figure 9-6). 

La gestion des erreurs 

La detection d'une situation d'erreur dans une des taches de la sequence peut provoquer l'interruption 
de la sequence et, eventuellement, la production et remission d'un message d'erreur SOAP. 

Dans la liaison SOAP/HTTP, les taches de reception et emission (en blanc dans la figure 9-6) sont 
executees par le serveur HTTP tandis que les taches d' analyse, d' evaluation et de traitement (en gris dans 
la figure 9-6) sont executees par le code technique et applicatif de 1' application SOAP. 

La detection d'une erreur ou defaillance peut donner lieu a trois types d'actions differentes : 

• une reponse HTTP au corps vide avec un code d'erreur ; 

• une reponse HTTP 500 contenant un message d'erreur SOAP ; 

• tout autre traitement de l'erreur different des deux actions precedentes. 

La premiere action est declenchee par l'agent logiciel consommateur et executee par le serveur 
HTTP. La deuxieme action est executee, toujours a l'initiative de l'agent logiciel consommateur, par 
le producteur du message SOAP et le serveur HTTP. La troisieme action est toujours declenchee par 
l'agent consommateur et executee en dehors de la chaine d'execution propre a la liaison SOAP/HTTP 
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L'architecture logicielle du noeud recepteur 

Dans F expose qui suit, nous allons considerer que les taches d' analyse, d' evaluation et de traitement 
sont executees en sequence stricte apres la reception. En effet, il s'agit d'une abstraction car souvent, 
dans la realite des applications, ces trois taches ne sont pas bien distinctes et F agent consommateur 
melange leurs executions. La separation des taches d'analyse, d' interpretation et de traitement est 
une bonne pratique, car il vaut mieux eviter de declencher des transitions d'etat et des effets de bord 
en tant qu'effet pragmatique d'un message syntaxiquement ou semantiquement defaillant (corres- 
pondant a un acte de communication manque !). 

En d'autres termes, Fanalyse syntaxique et revaluation semantique du message devraient etre entierement 
effectuees et reussies avant le declenchement chez le consommateur des traitements produisant les 
transitions d'etat et les effets de bord. 

Par ailleurs, ce comportement est obtenu par la gestion transactionnelle de la consommation du 
message SOAP. Une erreur semantique, ou meme syntaxique, du message SOAP peut etre detectee a 
la fin du traitement et provoquer de toute facon l'annulation {rollback) de la transaction. 

La gestion transactionnelle de la consommation du message permet done de melanger 1' analyse 
syntaxique, 1' interpretation semantique et la production de transitions d'etat. Cette demarche n'est 
pas applicable aux effets de bord, qui sont irreversibles par definition, et ne peuvent done pas etre 
annules. La presence d'effets de bord potentiels du traitement demande done, meme avec la gestion 
transactionnelle, un ordonnancement averti de ces effets, au moins apres tout controle syntaxique et 
semantique du message. 
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Les recommandations du profil de base, que nous avons rappelees tout au long de la presentation de SOAP, 

imposent, pour cause d'interoperabilite, des mesures fortes sur la gestion de la consommation d'un message 

SOAP et des erreurs SOAP (voir chapitre 7). 

Le profil de base exige que, lorsqu'une situation d'erreur est detectee suite a un message en erreur regu par un 

nceud SOAP 1.1, le traitement du message en erreur effectue par ce nceud n'aille pas au-dela des operations 

strictement necessaires au signalement de I'erreur (via un message d'erreur SOAP, la levee d'une exception, 

I'affichage d'une fenetre sur une console, ou tout autre moyen disponible dans le contexte et I'environnement de 

consommation du message). 

Le profil de base exige par ailleurs que dans le style d'echange requete/reponse SOAP, lorsqu'une situation 

d'erreur est detectee suite a une requete en erreur, la reponse contienne un message d'erreur SOAP. 



La problematique de 1' infrastructure transactionnelle est approfondie dans le chapitre 20 « Gestion 
des transactions ». Dans le present chapitre nous ne faisons aucune hypothese sur la gestion transac- 
tionnelle de la tache de consommation declenchee par la reception du message. En revanche, nous 
faisons F hypothese que les taches de consommation du message (analyse, evaluation et traitement) 
sont executees en sequence stricte. 

Nous allons presenter, pour le message a sens unique comme pour la requete/reponse, les differentes 
alternatives de synchronisation et d'ordonnancement des taches de reception/emission et de 
consommation et nous allons decrire plus en detail les strategies les plus utilisees. 
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Description des taches 

Nous allons decrire de facon sommaire les principales caracteristiques des taches de reception, 
d'analyse, d'evaluation et de traitement des messages SOAP, ainsi que la production du message 
SOAP et d'emission de la reponse HTTP (voir figure 9-6). 

La reception 



Agent logiciel Serveur HTTP 

Description Reception de la part du serveur HTTP de la requete HTTP. 

Conditions La requete HTTP correctement formulee, contenant un document XML bien forme, est correctement regue 

de reussite par le serveur HTTP non defaillant. Si les conditions de reussite sont remplies, le message est bien recu 

et passe avec le controle d'execution a la tache d'analyse. 

Causes Les causes d'echec appartiennent a trois categories : 

d'echec - message physique mal forme (enveloppe HTTP, message SOAP emboite) ; 

- defaillance de la connexion ; 

- defaillance du recepteur. 

Si un echec se produit, quelle qu'en soit la cause, la sequence est interrompue et une sortie d'erreur est 
generee. 



L'analyse syntaxique 



Agent logiciel 
Description 



Conditions 
de reussite 



Causes 
d'echec 



Analyseur syntaxique SOAP 

Analyse syntaxique du message SOAP (qui, ayant passe I'etape de reception, est un document XML bien 

forme). 

Validation par rapport aux differents schemas XML Schema references par le message. 

Pour les messages encodes, analyse de I'application correcte du style de codage. 

Les conditions de reussite de la tache sont reunies si I'enveloppe SOAP regue est syntaxiquement cor- 
recte et conforme a la version de SOAP acceptee par le recepteur/consommateur. Si les conditions de 
reussite sont satisfaites, le controle d'execution et le message sont passes a la tache d'evaluation seman- 
tique. 

Les causes d'echec appartiennent a quatre categories : 

- invalidite (non conformite par rapport a un schema XML Schema) ; 

- mise en ceuvre incorrecte du style de codage revendique ; 

- version SOAP non geree par le consommateur du message ; 

- defaillance de I'analyseur. 

Dans le cas standard, un echec interrompt I'execution de la sequence et genere une sortie d'erreur. Un 
analyseur « intelligent », coordonne avec un evaluateur « intelligent », pourrait passer le message avec 
des erreurs syntaxiques a la tache d'evaluation, executee dans un mode « simule », dans le but de 
collecter le maximum d'informations d'analyse et d'evaluation avant I'interruption de I'execution de la 
sequence. La sequence est de toute facon interrompue avant la tache de traitement par une sortie 
d'erreur. 
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L'evaluation semantique 

Agent logiciel Evaluateur semantique SOAP et applicatif 

Description Evaluation semantique du message SOAP bien recu et syntaxiquement correct (sauf cas d'essai d'eva- 

luation semantique de messages avec des erreurs syntaxiques pour collecte d'informations d'erreur - 
analyseur et evaluateur intelligents). 

L'evaluation semantique est une tache de controle essentiellement applicative : elle consiste a appliquer 
non seulement les regies de controle semantique SOAP, mais aussi toutes les regies de controle metier 
sur le contenu du message. 
Les regies de controle semantique verifient essentiellement que : 

- le producteur/emetteur du message a les capacites, les droits et les autorisations de production/emission 
du message ; 

- le recepteur/consommateur a les capacites, les droits et les autorisations de reception/consommation 
du message ; 

- le message est correct et pertinent dans le contexte et I'environnement de sa transmission. 

Conditions La condition de reussite de la tache devaluation semantique est acquise si le message est semantiquement 

de reussite correct, du point de vue des regies de controle semantique SOAP et des regies de controle metier. 

Si les conditions de reussite sont remplies, le message est passe avec le controle d'execution a la tache 

de traitement. 

Causes Les causes d'echec appartiennent a quatre categories : 

d'echec - le message est semantiquement defaillant ; 

- le producteur/emetteur n'a pas les droits ni les autorisations pour produire et emettre le message ; 

- le recepteur/consommateur n'a pas les capacites, les droits ou les autorisations pour receptionner et 
consommer le message ; 

- I'evaluateur semantique est defaillant. 

L'echec interrompt I'execution de la sequence et provoque une sortie d'erreur. 



Le traitement 



Agent logiciel 
Description 



Conditions de 
reussite 



Causes 
d'echec 



Application metier traitante 

Le traitement est une tache purement applicative : il s'agit de I'execution des regies de traitement metier, 
declenchees par la reception d'un message syntaxiquement et semantiquement correct, qui produisent 
les calculs, les transitions d'etat et les effets de bord. 

Les conditions de reussite de la tache sont remplies si les calculs, les transitions d'etat et les effets de 
bord, que la reception du message SOAP syntaxiquement et semantiquement correct est censee declencher, 
sont correctement et completement effectues. 

Dans le cas de consommation totalement synchrone d'une requete SOAP, lorsque les changements 
d'etat et les effets de bord sont accomplis avec succes, les resultats du traitement et le controle d'execu- 
tion sont passes aux taches de production/emission de la reponse SOAP. 

Elles ne se produisent que sur defaillance de I'application metier traitante. 

La tache de traitement recoit en entree un message syntaxiquement et semantiquement correct : elle doit 
done produire les calculs, les transitions d'etat et les effets de bord engendres par la reception du 
message. L'echec ne peut etre cause que par la defaillance de I'agent logiciel executant la tache (nous 
considerons la defaillance des ressources materielles et logicielles utilisees par I'application traitante 
comme une defaillance de I'agent logiciel). 
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La production 

Agent logiciel Producteur de message SOAP. 

Description La production correspond a la mise en forme d'un message SOAP (message d'erreur, reponse) avant son 

emission. 

L'emission 

Agent logiciel Serveur HTTP 

Description Production et emission de la reponse HTTP. 

Modalites de synchronisation du message SOAP avec la requete/reponse HTTP 

Les modalites de synchronisation du message SOAP (a sens unique ou requete) avec la requete/ 
reponse HTTP sont presentees dans le tableau suivant. 
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Nous allons maintenant detailler les deux modalites « naturelles 
consommation du message SOAP et la requete/reponse HTTP : 

• reception synchrone du message a sens unique ; 

• consommation totalement synchrone de la requete. 



de synchronisation entre la 
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La reception synchrone du message a sens unique SOAP 

La modalite de reception synchrone du message a sens unique SOAP sur la liaison SOAP/HTTP 
prevoit remission de la part du serveur HTTP de la reponse HTTP 202 Accepted a la terminaison 
reussie de la tache de reception (voir figure 9-7). 
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Figure 9-7 

Reception synchrone d'un message a sens unique sur la liaison HTTP. 

Les taches d' analyse, d' evaluation et de traitement sont ordonnancees pour execution asynchrone par 
rapport a la requete/reponse HTTP. La reponse HTTP est done un compte rendu de reussite de la 
reception (accuse de reception), ou bien un compte rendu d'echec de reception (erreur de reception). 

En d'autres termes, avec cette modalite de synchronisation, le producteur/emetteur n'a aucun compte 
rendu synchrone de Fanalyse, de revaluation ou du traitement du message SOAP. 

Une reponse HTTP 4xx est produite par la tache de reception et relate une erreur de reception 
(message mal forme, defaillance de la connexion). La defaillance du recepteur, si elle est rattrapee, 
declenche une reponse HTTP 500 Internal Server Error. 
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Une reponse HTTP 500 avec le corps HTTP vide est emise par la tache de reception et signale une 
defaillance du serveur HTTP qui a arrete F execution. 
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Un noeud emetteur SOAP d'un message a sens unique ne doit pas considerer que I'interaction avec le recepteur 
est complete avant d'avoir recu la reponse HTTP 202 Accepted. Cette reponse ne doit en aucun cas etre inter- 
pretee comme une validation syntaxique et/ou semantique du message, ou comme un engagement a traiter le 
message (R2715). C'est la raison pour laquelle nous nous sommes limites a detainer seulement la reception 
synchrone du message a sens unique. 



Consommation totalement synchrone d'une requete SOAP 

La modalite de consommation totalement synchrone pour la requete SOAP sur la liaison SOAP/ 
HTTP (voir figure 9-8) prevoit : 

• 1' execution en sequence stricte des taches de reception, d' analyse, d' evaluation et de traitement ; 

• la production immediate, a la terminaison reussie de la tache de traitement, de la reponse SOAP ; 

• la production et remission immediates de la reponse HTTP 200 OK avec la reponse SOAP emboitee. 
La reponse SOAP dans le corps de la reponse HTTP 200 contient generalement : 

• le compte rendu de reussite de l'execution de la tache de traitement, qui peut inclure les comptes 
rendus detailles de reussite de l'execution des taches precedentes dans la sequence (generalement 
implicite a cause de F engagement d' interruption de la sequence de taches avant le traitement) ; 

• les informations qui resultent du traitement (eventuellement). 

Une reponse HTTP 4xx avec le coips HTTP vide (sans message SOAP) est emise par la tache de 
reception et relate une erreur de reception. 

Une reponse HTTP 500 avec le corps HTTP vide (sans message SOAP) est emise par la tache de 
reception et signale une defaillance du serveur HTTP qui a arrete l'execution de la sequence. 

Une reponse HTTP 500 avec un message d'erreur SOAP SOAP-ENV:VersionMismatch est emise par la 
tache d' analyse pour indiquer Fincapacite du recepteur/consommateur a traiter la version SOAP du 

message. 

Une reponse HTTP 500 avec un message d'erreur SOAP SOAP- ENV: Client est emise par la tache 
d' analyse ou d' evaluation et decrit une ou plusieurs erreurs syntaxiques ou semantiques (un analyseur 
et un evaluateur intelligents essayent d'aller le plus loin possible dans Fanalyse et Fevaluation du 

message). 

Une reponse HTTP 500 avec un message d'erreur SOAP SOAP-ENV:MustUnderstand est emise par la 
tache d' evaluation et signale Fincapacite, de la part du recepteur/consommateur du message, a 
consommer effectivement le message (a executer les taches devaluation et traitement sur le message 
recu). 

En conformite avec les specifications SOAP 1.1, les elements faultstring et detail de S0AP-ENV: Fault 
doivent etre presents et renseignes lorsque le corps du message SOAP ne peut pas etre evalue ou 
traite. Cette documentation d'erreur n'est pas normalisee et peut faire Fobjet d'un accord entre les 
interlocuteurs. 
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Figure 9-8 

Consommation totalement synchrone d'une requete SOAP sur la liaison HTTP. 
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Une reponse HTTP 500 avec un message d'erreur SOAP code SOAP- ENV: Server peut etre emise, soit 
par la tache d' analyse, soit par la tache d' evaluation, soit par la tache de traitement et relate respecti- 
vement une defaillance, soit de Fanalyseur, soit de Fevaluateur, soit de F application traitante. La 
documentation de la localisation et de la nature de la defaillance (elements f aul tstri ng et detai 1 de 
SOAP-ENV : Faul t) n'est pas normalised et peut faire l'objet d'un accord entre les interlocuteurs. 

L'appel de procedure distante (RPC) en SOAP 

Le style d'echange entre applications reparties nomme appel de procedure distante (RPC ou Remote 
Procedure Call) presente de nombreux avantages, qui Font rendu populaire aupres des developpeurs. 

L'avantage essentiel du style d'echange RPC est son caractere intuitif par rapport a des habitudes de 
programmation generalement acquises. II permet, dans certaines limites, de presenter le traitement 
qui peut etre effectue par un programme s'executant sur un nceud distant du reseau comme equivalent 
a l'execution d'une sous-routine dans Fespace de travail local. 

Le succes grandissant de la programmation par objets et des architectures a objets repartis a confirme 
la popularite du style RPC, qui s'est transforme en invocation de methode distante (RMI ou Remote 
Method Invocation) : la methode a executer est une procedure identifiee non seulement par son nom 
et sa signature, mais aussi par le nom de la classe de l'objet (le contexte de resolution du nom de la 
procedure est relatif a la classe de l'objet cible, compte tenu des regies d'heritage). Pour invoquer la 
methode, il est necessaire de disposer de l'identifiant absolu de l'objet sur lequel la methode est 
invoquee. 



Implementations du style RPC 

Le style RPC a ete normalise dans le contexte de I'initiative DCE (Distributed Computing Environment) ou encore 
mis en oeuvre dans la realisation de NFS, le systeme de fichiers repartis que Sun Microsystems a rendu populaire 
dans la communaute Unix. 

Les mecanismes de RPC sont offerts par un nombre important d'editeurs de logiciels et de fournisseurs de systemes 
d'exploitation. Le modele le plus utilise est probablement celui defini par I'OSF (Open Software Foundation) dans 
le cadre de DCE. L'OMG (Object Management Group) propose dans CORBA (Common Object Request Broker 
Architecture) un modele d'appel de procedure distante qui utilise les fonctions du « courtier » (ORB ou Object 
Request Broker) d'objets repartis. Sun Microsystem propose RMI (Remote Method Invocation), un modele de RPC 
integre dans le langage Java, qui permet d'invoquer une methode rattachee a un objet resident dans une machine 
virtuelle Java (processus) differente de celle du programme appelant. RMI utilise aujourd'hui un protocole de 
transport identique a celui impose par I'OMG pour assurer I'interoperabilite entre differentes implementations d'ORB 
(NOP ou Internet Inter-ORB Protocol). 



Du point de vue du style d'echange entre applications reparties, le style RPC est un cas particulier du 
style requite/ 'reponse. 

La requete contient une representation de Finvocation de la procedure. 
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La reponse contient : 

• soit une representation du compte rendu de reussite de l'execution de la procedure, ainsi qu'eventuel- 
lement des donnees resultat de l'execution de la procedure ; 

• soit un compte rendu d'echec, sous forme de message d'erreur. 

Le style requete/reponse appele « document » peut etre defini comme le complement du style RPC 
car il est utilise par les requetes/reponses SOAP qui ne transportent pas d'appels/retours RPC. 

La declinaison du style RPC la plus utilisee et la plus simple a programmer est Yappel bloquant de 
procedure distante a execution synchrone. 

L'appel bloquant de procedure distante a execution synchrone 

Dans l'appel bloquant de procedure distante a execution synchrone, la ligne d'execution (thread) de 
l'application cliente qui effectue l'appel realise en fait un appel local a un composant logiciel (appele 
stub ou proxy) et suspend l'execution en attente du retour de cet appel. 

En cas de succes, le stub retourne, apres un temps de latence raisonnable, le compte rendu et eventuel- 
lement les resultats de l'execution de la procedure appelee. 

En cas d'echec, detectable par le stub, celui-ci, soit retourne un compte rendu d'echec, soit leve une 
exception qui est rattrapee par le programme appelant. Les cas d'echec comprennent egalement les 
depassements du delai d' attente maximal, qui placent le programme appelant dans une situation 
d' incertitude. 

Lattrait de l'appel bloquant de procedure distante a execution synchrone tient au fait qu'il reduit, 
lorsqu'il est reussi et dans certaines situations d'echec, le modele parallele et concurrent des traitements 
repartis au modele sequentiel/recursif de l'appel de sous-programme. 

En ce qui concerne la ligne d'execution appelante, en cas de reussite ou dans des situations d'erreur 
imputables a F appele, tout se passe, a peu de choses pres, comme lors de l'appel d'une procedure locale 
s'executant dans le meme espace de travail. Les developpeurs habitues a ce type de programmation, 
a savoir une ecrasante majorite, ne sont pas depayses. 

La difference avec l'appel de procedure local devient explicite lorsque des erreurs se produisent et il 
est impossible d'occulter le fait que l'appel et le retour de l'appel se sont transformes en messages 
echanges sur le reseau avec une application s'executant sur un autre nceud. Les situations anormales 
qui peuvent se produire et qui ne rentrent pas dans le canevas de l'appel de procedure locale sont 
done de trois types : 

• dysfonctionnement ou defaillance de la connexion ; 

• dysfonctionnement ou defaillance de l'application distante ; 

• temps de latence trop long, au-dela du delai d' attente maximal que peut se permettre la ligne 
d'execution (thread) appelante. 

Le depassement du delai d'attente maximal (timeout) pose probleme car le processus appelant peut se 
trouver dans une situation ou il ne sait pas faire la distinction entre un temps de latence trop long et 
certaines defaillances de la connexion ou de l'application distante. 
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Ces cas anormaux cassent le mimetisme avec l'appel de procedure distante et ramenent le style RPC 
a une declinaison particuliere du style d'echange requete/reponse entre applications reparties. 

Des variantes du style RPC, plus complexes que le simple appel bloquant de procedure distante a 
execution synchrone, sont souvent mises en ceuvre, comme : 

• l'appel non bloquant : la ligne d'execution appelante reprend le controle d'execution immediatement 
apres l'appel et un mecanisme de rendez-vous ou de call-back permet de recuperer, le moment 
venu, le compte rendu et les resultats de 1' execution de la procedure distante ; 

• F execution partiellement ou totalement asynchrone de la procedure distante, par F introduction de 
formes d'asynchronisme comme celles evoquees dans la section precedente. 

L'appel non bloquant et F execution asynchrone de la procedure distante proposent des modeles de 
communication entre applications reparties qui s'eloignent de plus en plus de la simplicite intuitive 
de l'appel local de sous-programme. 

La dynamique de l'appel bloquant de procedure distante 
a execution synchrone 

L' execution d'un appel bloquant de procedure distante a execution synchrone repose sur une 
architecture logicielle qui comprend les composants suivants : 

Du cote de F application cliente : 

• Le programme appelant, qui lance l'appel de procedure distante comme un appel local vers un 
composant logiciel appele stub et suspend F execution en attente du retour de l'appel de la part du 
stub. 

• Le composant logiciel nomme stub (ou parfois proxy), qui peut etre considere comme le representant 
local de la procedure distante, du cote client. Ce composant est invoque par le programme appelant 
pour generer une representation lineaire de l'appel qui puisse etre emboitee dans un message transi- 
tant sur le reseau (serialisation). Cette representation lineaire est passee au composant en charge de 
Femission (et de la reception) du message que nous appelons « composant communication » (voir 
ci-apres). Reciproquement, il est sollicite par le composant communication avec la representation 
lineaire du retour de l'appel de la procedure distante : cette representation est transformee en retour 
de l'appel (deserialisation). 

• Un composant communication, faisant partie de F infrastructure d'echange, qui se charge de la 
production et de Femission du message dans lequel est emboitee la representation lineaire de 
l'appel. II se charge egalement de la reception du message qui incorpore la representation lineaire 
du retour de l'appel, ainsi que de F extraction de cette representation et de sa transmission au stub. 

Du cote de F application serveur : 

• Un composant communication, faisant partie de F infrastructure d'echange, qui se charge de la 
reception du message/appel, de l'extraction de la representation lineaire de l'appel, de Finvocation 
d'un composant appele skeleton avec la representation lineaire passee en parametre. Reciproquement, 
il est charge de la production et de Femission du message emboitant la representation lineaire du 
retour de l'appel qui lui est transmise par le skeleton. 
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• Un composant logiciel nomme skeleton (ou parfois stub) qui peut etre considere comme le repre- 
sentant local du programme appelant, du cote serveur. Ce composant a pour tache de transformer 
la representation lineaire de l'appel, recue de la part du composant communication, en un appel 
local vers la procedure invoquee (deserialisation). Reciproquement, il est charge de produire une 
representation lineaire (serialisation) du retour de 1' execution de la procedure et de la transferer au 
composant communication. 

• Le programme appele, qui subit l'appel de procedure locale de la part du skeleton, execute la 
procedure et retourne le compte rendu d' execution et eventuellement les resultats du traitement au 
skeleton. 

Le g raphe de sequence d'une RPC 

La dynamique de l'appel bloquant de procedure distante est presentee figure 9-9. 

Le pretraitement 

Le programme appelant, au cours de son execution, effectue un appel de procedure distante. Cet 
appel est en fait un appel local au stub. La ligne d' execution du programme appelant suspend son 
activite et se met en attente du retour du stub. 

La serialisation 

Le stub serialise l'appel (en genere une representation lineaire). Cette representation lineaire 
comprend la representation des valeurs des arguments de l'appel, qui est construite selon des regies 
de codage des types atomiques et structures des arguments. La serialisation relative a une signature de 
methode ou a une procedure donnee peut etre effectuee systematiquement par un stub specifique (le 
stub est genere a la compilation a partir de la signature). Elle peut aussi etre produite dynamiquement par 
un stub generique charge d' interpreter a la volee la description de la signature, qui doit etre evidemment 
accessible a l'execution. Le stub doit egalement disposer de l'adresse du port de reception du serveur, 
qu'il peut connaitre statiquement ou qu'il trouve sur un annuaire. Le stub appelle le composant 
communication en fournissant en parametre la representation lineaire de l'appel et l'identifiant/ 
adresse du serveur, et se met en attente du retour. 

L'emission 

Cote client, le composant communication emboite la representation lineaire de l'appel dans un message 
qui est transmis, au moyen d'un protocole reseau, a son correspondant sur le serveur. 

La reception 

Cote serveur, le composant communication est sollicite par la reception du message. Par inspection de 
certaines parties du message (generalement de l'en-tete), il trouve l'adresse du skeleton correspondant 
et effectue un appel en passant la representation lineaire de l'appel en parametre. 
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La deserialisation 

Le skeleton transforme la representation lineaire de l'appel en un appel local a la procedure visee 
(deserialisation). 
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Figure 9-9 

Graphe de sequence de l'appel bloquant de procedure distante a execution synchrone. 
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Le traitement 

La procedure s'execute et retourne le compte rendu d' execution avec eventuellement les resultats au 
skeleton. La procedure peut egalement produire des exceptions. 

La serialisation 

Le skeleton serialise le compte rendu d' execution (eventuellement les resultats) ou produit une represen- 
tation lineaire (message d'erreur) d'une exception levee par la procedure. II passe la representation 
lineaire au composant communication. 

L'emission 

Cote serveur, le composant communication emboite la representation lineaire du retour d'execution, 
reussie ou en erreur, dans un message et transmet le message a son correspondant client. 

La reception 

Cote client, le composant communication recoit le message qui transporte le retour de l'appel. II 
extrait du message la representation lineaire du retour qu'il passe au stub en attente de ce retour. 

La deserialisation 

Le stub transforme la representation lineaire du retour en un retour d'appel local vers le programme 
appelant ou bien en levee d'exception (deserialisation). Pour cela, il utilise les regies de decodage des 
types atomiques et structures. Si le compte rendu de l'appel est un compte rendu d'echec, il peut lever 
une exception. 

Le post-traitement 

Le programme appelant recupere le retour de l'appel au stub ou rattrape 1' exception levee et continue 
son traitement applicatif. 

La mise en ceuvre du style RPC avec SOAP 

La representation et l'echange d'appels de procedure distante via l'utilisation de XML et des protocoles 
Internet est l'objectif originel de SOAP. La motivation principale n'est pas la consequence, selon 
nous, d'une predilection pour ce style d'echange entre applications reparties, mais vient de deux 
constats pragmatiques : 

• Une partie tres importante des applications patrimoniales, quelle que soit leur technologie 
d' implementation, presente une interface « locale » sous forme d'API (Application Programming 
Interface), c'est-a-dire sous forme de signatures de procedures ou de methodes : dans ce cas, la 
mise en ceuvre d'un skeleton SOAP suffit pour exposer leur API, la rendre accessible en style RPC 
et transformer ainsi ces applications en services Web. 

• Pour les applications patrimoniales qui ne presentent pas une interface locale sous forme d'API 
(comme certaines applications TP sur mainframe), la mise en ceuvre d'une telle interface locale, 
completee par la realisation d'un skeleton SOAP, est le moyen le plus simple pour les transformer 
en services Web. 
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SOAP 1.1 definit une representation lineaire des appels de procedures distantes et des retours d'appels. 
Cette representation lineaire peut etre utilisee en synergie avec une representation codee des donnees 
atomiques et structurees, valeurs des parametres d'entree et de sortie du style RPC, et eventuellement 
avec le style de codage SOAP 1.1 (voir chapitre 8). Cependant, l'usage du style de codage SOAP 1.1 
n'est pas une obligation car la representation RPC SOAP est volontairement independante de tout 
style de codage. 

L' utilisation de SOAP pour la representation du style RPC est egalement independante, en principe, 
du protocole utilise pour l'echange des messages. Dans le cas de Futilisation de la liaison generique 
SOAP/HTTP, le style RPC devient une declinaison tres naturelle du style requete/reponse qui 
s'appuie, lui aussi tres naturellement, sur le couple requete/reponse HTTP. 

L'utilisation d'autres protocoles de transport, comme SMTP, est toujours possible et des implemen- 
tations sont disponibles. II faut cependant garder a l'esprit que la liaison generique SMTP sur 
SOAP 1.1 n'est pas definie explicitement dans la specification. Les implementations existantes 
doivent done etre considerees comme des extensions proprietaries du protocole SOAP 1 . 1 (meme si 
des notes relatives a ce sujet ont ete soumises au W3C). Par ailleurs, la nature nativement asyn- 
chrone de SMTP permet de mettre en ceuvre facilement des variantes non bloquantes et asynchrones 
du style RPC. 

Pour mettre en ceuvre le style RPC en SOAP, il est necessaire de disposer des informations suivantes : 

• l'URI de la cible ; 

• le nom de la procedure ou de la methode ; 

• la signature de la procedure ou de la methode (necessaire pour composer un appel dynamique) ; 

• les parametres de 1' appel et du retour. 

Utilisation de l'URI comme identifiant de la cible 

La cible d'un appel de procedure distante est l'entite a laquelle l'appel est adresse. La cible se distingue 
par sa granularite. Elle peut etre : 

• un objet (une occurrence d'une classe) dans le cas de l'invocation de methode distante ; 

• une application entiere, a savoir un processus s'executant sur une machine distante dont le nom de 
la procedure designe un point d'entree (entry-point). 

Le choix, realise par la technologie de services Web, a consiste a choisir l'URI comme identifiant 
universel pour ces deux types de cible. Cela veut dire que, quelle que soit la granularite de la cible, 
elle se presente toujours comme une ressource Web. Ce choix presente des avantages tres importants dont 
la portee et les consequences ne sont probablement pas encore completement identiflees aujourd'hui : 

• II s'agit d'une solution generale et hautement interoperable du probleme de 1' identifiant universel 
de la cible de l'appel, dont les solutions n'ont pas toujours ete satisfaisantes dans le passe. LTOR 
(Interoperability Object Reference) de l'OMG est arrive tardivement avec CORBA 2, car l'identi- 
fiant de F objet cible a longtemps ete considere comme relevant de 1' implementation proprietaire 
del'ORB. 
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• II garantit le traitement homogene d' un objet ou d' un processus distant (en fait d' un service) comme 
une ressource Web, au meme titre qu'une page HTML ou un document PDF. 

De ce choix decoulent des consequences interessantes, telles que : 

• le fait que Ton puisse inserer dans une page HTML le lien a FURI de la cible d'une invocation 
RPC SOAP (et en general d'un message SOAP), mais encore faut-il que le navigateur sache ce 
qu'il faut faire avec ce lien, et avec le message SOAP renvoye apres avoir clique sur le lien ; 

• la possibilite que les cibles de l'appel soient creees automatiquement par le serveur et retournees 
au client (sous forme de donnees de type xsd : anyURI), comme pour la creation dynamique d'objets 
repartis. 

Par exemple, le service « Voyages d'affaires », que nous avons decrit dans le chapitre 4, est identifie 
par un URI, et peut retourner FURI d'un (dossier de) voyage d'affaires, lequel constituera, apres 
insertion dans une page HTML personnalisee sous forme de lien, la cible directe d'autres invocations 
RPC appropriees. II faut noter que ce mode de fonctionnement est tres puissant, mais il reintroduit les 
problemes, propres a la programmation par objets repartis, de cycle de vie et de portee de l'identifiant. 

L'utilisation de l'URI de la cible de l'invocation RPC est deleguee par SOAP a la liaison avec le 
protocole de transport. Dans la liaison SOAP/HTTP, l'URI de la cible de l'invocation RPC est FURI 
de la requete (champ Host). 

La representation du style RPC dans le corps SOAP 

Les appels et les retours d'appels RPC sont vehicules sous forme de descendants directs du corps 
d'un message SOAP 1.1 (SOAP-ENV:Body). 

L'appel de procedure est represente par un element conteneur (wrapper), nomme et type en utilisant 
le nom de la methode appelee. 

Les parametres d' entree de l'appel sont des accesseurs, dont le nom et le type correspondent au nom 
et au type de chaque parametre, et constituent des descendants directs du conteneur. Les accesseurs 
dans le conteneur sont disposes dans le meme ordre que les arguments dans la signature de la 
methode. 

Le retour de l'appel de procedure est represente lui aussi par un element conteneur. Le nom de 
Felement n'est pas impose et n'est pas signifiant. La convention d'usage est d'utiliser le nom de la 
procedure avec en suffixe Response. 

La valeur de resultat de l'appel n'a pas de nom signifiant, mais represente le premier descendant 
direct de Felement conteneur. 

Les parametres de sortie de l'appel sont des accesseurs, dont le nom et le type correspondent au nom 
et au type de chaque parametre. Les accesseurs dans Felement composite sont disposes dans le meme 
ordre que les arguments dans la signature de la procedure ou methode, apres le resultat. 
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Distinction entre usage litteral et usage code 

Le style d'echange RPC ou document d'une « operation » mise en ceuvre par une requete/reponse SOAP est 
precise dans un document WSDL (voir chapitre 1 0) par la valeur de I'attribut styl e de I'element soap : opera ti on 
(le prefixe soap est associe au vocabulaire XML http://schemas.xmlsoap.org/wsdl/soap). Les valeurs possibles de 
I'attribut styl e sont rpc (pour le style RPC SOAP) et document (pour le style requete/reponse generique). 
Par ailleurs, I'indication du type et de la structure concrete d'un message est obtenue par les attributs type et 
el ement de I'element WSDL message, dans la description de I'interface abstraite. Les valeurs de ces attributs sont 
des noms de types et d'elements definis dans I'element types du document WSDL. L'element types peut contenir 
un ou plusieurs schemas XSD (encapsules par I'element xsd: schema) ou d'autres schemas (definis dans un 
langage autre que XML Schema). 

La relation entre les schemas et la structure du message est complexe et passe egalement par I'attribut use de 
soap: body, qui caracterise la structure du corps SOAP pour une operation vehiculee par I'intermediaire du 
protocole SOAP. Les valeurs de use sont 1 iteral et encoded. 

Lorsque la valeur de I'attribut use est literal (usage litteral), les valeurs de type ou element de message 
definissent la structure concrete du message. L'attribut encodingStyle peut etre specifie, mais il n'a qu'une 
valeur de commentaire de tragabilite : il exprime simplement que le style de codage identifie par sa valeur (par 
exemple le style de codage SOAP 1.1) a ete utilise pour produire la structure du message concret, mais que 
finalement il ne faut tenir compte que de la structure produite, qui est entierement decrite dans I'element WSDL 
types, et non de la procedure d'encodage (c'est une strategie qualifiee sender-makes-right qui s'applique). 
Lorsque la valeur de use est encoded (usage code), I'attribut encodingStyle donne I'identifiant du style de 
codage qui est applique pour generer un message concret (pour le style de codage SOAP 1.1, I'identifiant est I'URI 
http://schemas.xmlsoap.org/soap/encoding). La valeur de type de message donne une indication d'un 
type « abstrait », car, pour obtenir le message concret, il est necessaire d'appliquer les regies de codage propres 
au style de codage (par opposition a I'usage litteral, ou la structure concrete du message est parfaitement indiquee 
par le schema). Le recepteur d'un message SOAP, defini avec ces caracteristiques dans I'element WSDL service, 
est dote d'une procedure de decodage complexe, car il doit etre capable d'absorber les differentes variantes du 
style de codage SOAP 1.1 (dans ce cas, c'est une strategie qualifiee receiver-makes-right qui s'applique). 
II faut bien noter que I'usage litteral de SOAP (valeur 1 i teral de use) englobe les representations litterales et 
les representations codees implicites, voire explicites (voir I'usage de encodingStyle evoque dans la section 
precedents). 

Dans les exemples qui suivent, le prefixe destine aux types definis dans le style de codage SOAP 1.1 (http:// 
schemas .xml soap.org/soap/encoding) est SOAP-ENC. 



Evolutions SOAP 1.2 (draft) 

SOAP 1 .2 propose un accesseur res u 1 1 du vocabulaire XML SOAP/RPC pour designer dans la reponse I'element 

qui transporte le resultat de I'appel RPC, ainsi que des codes d'erreur additionnels (toujours dans I'espace de 

noms SOAP/RPC). 

SOAP 1.2 permet de representor les requetes et les reponses non seulement comme des structures, mais aussi 

comme des vecteurs. 

II faut rappeler que la specification SOAP 1 .2 considere optionnelle I'implementation du style de codage SOAP 1 .2. 
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Usage litteral pour le style RPC 

Voici un exemple de RPC SOAP, en usage litteral, vehicule par une liaison SOAP/HTTP 

Appel 

L'appel RPC : 

POST /RentACar HTTP/1.1 

Host: webserver.carrental.com 

Content-Type: text/xml ; charset="utf-8" 

Content-Length: nnnn 

SOAPAction: "http://webserver.carrental .com/RentACar" 

<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope 

xmlns: SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Body> 

<lrac: get LastDaily Rate xmlns :lrac="http:// rentacar.org/literal"> 
<1 rac:carClass>A</l rac:carClass> 
<1 rac:carMake>Peugeot</l rac:carMake> 
</lrac:getLastDailyRate> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Dans cet exemple : 

• La cible est designee par la valeur du champ d'en-tete de la requete HTTP Host. 

• Le but du message est designe par la valeur du champ d'en-tete SoapActi on. 

• L invocation de la procedure est representee par F element composite getLastDai lyRate, descendant 
direct de SOAP- ENV: Body. 

• La. procedure se nomme getLastDailyRate. 

• L'invocation de la procedure comporte deux parametres : carCl ass et carMake. 

• Le vocabulaire XML http: //rentacar .org/1 iteral est associe au schema XSD qui definit le schema 
de l'appel. 

Voici la definition des types des valeurs des parametres carCl ass et carMake : 

<xs:simpleType name="CarClassType"> 

<xs: restriction base="xs:string"> 
<xs:length value="l" fixed="true"/> 

</xs : restriction> 
</xs:simpleType> 
<xs:simpleType name="CarMakeType"> 

<xs: restrict!' on base="xs:string"/> 
</xs:simpleType> 

Voici le type complexe correspondant a la structure de l'appel : 

<xs:complexType name="getl_astDailyRateType"> 
<xs:sequence> 

<xs:element name="carClass" type="tns:CarClassType"/> 
<xs:element name="carMake" type="tns:CarMakeType"/> 
</xs :sequence> 
</xs:complexType> 
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Enfin, voici F element getLastDailyRate : 

<xs: element name=" get Last Daily Rate" type="tns:getLastDailyRateType"/> 

Retour 

Le retour d'appel RPC : 

HTTP/1.1 200 OK 

Content-Type: text/xml ; charset="utf-8" 

Content-Length: nnnn 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

xml ns : SOAP- ENV=" http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Body> 

<1 rac:getLastDailyRateResponse xml ns:lrac="http: //rentacar. org/1 iteral"> 
<1 rac:return>26</lrac:return> 
<1 rac:currency>Euro</l rac:currency> 
<1 rac:carMake>Renault</l rac:carMake> 
</lrac:getLastDailyRateResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Voici les definitions des types des parametres : 

<xs:simpleType name="DailyRateType"> 
<xs: restriction base="xs:float"/> 
</xs :simpleType> 

<xs : simpl eType name="CurrencyType"> 
<xs: restriction base="xs:string"> 
<xs:enumeration val ue="Euro"/> 
<xs: enumeration val ue="Dol lar"/> 
<xs:enumeration val ue="Yen"/> 
</xs: restrict!' on> 
</xs : simpl eType> 

Voici la definition du type et de l'element « retour d'appel » : 

<xs : compl exType name= "get Last Dai lyRateResponseType"> 
<xs:sequence> 

<xs:element name="return" type="tns:DailyRateType"/> 
<xs:element name="currency" type="tns:CurrencyType"/> 
<xs:element name="carMake" type="tns:CarMakeType"/> 
</xs:sequence> 
</xs : compl exType> 

<xs:element name="getLastDailyRateResponse" 
type="tns :getLastDailyRateResponseType"/> 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Nous rappelons que le profil de base n'accepte, pour cause d'interoperabilite, que I'usage litteral du style RPC. 
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Usage litteral avec revendication du style de codage 

Voici le meme exemple qu'a la section precedente, toujours en usage litteral. Les types sont obtenus 
par extension/restriction des types du style de codage SOAP 1.1 dont le schema concret du message 
est obtenu par les definitions des types et des elements. Dans ce cas, l'indication du style de codage 
(SOAP-ENV:encodingStyle), si elle est utilisee, sert simplement de documentation sur la production du 
message. 

Nous presentons seulement l'appel : 

POST /RentACar HTTP/1.1 

Host: webserver.carrental.com 

Content-Type: text/xml ; charset="utf-8" 

Content-Length: nnnn 

SOAPAction: "http://webserver.carrental .com/RentACar" 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 
xmlns : SOAP -ENV=" http://schemas.xml soap.org/soap/envelope/"> 
<SOAP-ENV:Body> 
<1 rac:getl_astDailyRate xmlns :1 rac="http: //rentacar. org/1 iteral"> 
<lrac:carClass>A</l rac:carClass> 
<lrac:carMake>Peugeot</lrac:carMake> 
</lrac:getLastDailyRate> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

La cible et le but de l'appel sont precises de la meme facon que dans la section precedente. La structure 
de l'appel est aussi la meme. Seule la revendication de style de codage SOAP 1.1 est ajoutee. 

Voici la definition du type des valeurs du parametre carCl ass (la definition relative a carMake reste la 
meme que dans 1' exemple precedent) : 

<xs:complexType name="CarClassType"> 
<xs:simpleContent> 

<xs: restriction base="SOAP-ENC:string"> 

<xs:length value="l" fixed="true"/> 
</xs: restrict!' on> 
</xs :simpleContent> 
</xs:complexType> 

Le type complexe correspondant a la structure de l'appel est une structure du style de codage SOAP 1.1 : 

<xs : compl exType name="getLastDai ly RateType"> 
<xs:complexContent> 

<xs:extension base="SOAP-ENC:Struct"> 
<xs:sequence> 

<xs:element name="carCl ass" type="tns:CarClassType"/> 
<xs:element name="carMake" type="tns:CarMakeType"/> 
</xs:sequence> 
</xs:extension> 
</xs : compl exContent> 
</xs: compl exType> 
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Voici enfin 1' element getLastDailyRate : 

<xs: element name=" get Last Daily Rate" type="tns:getLastDailyRateType"/> 

Usage code 

Dans l'exemple qui suit, les types sont obtenus par extension/restriction des types du schema de 
codage SOAP 1.1. Bien que les elements et les types soient parfaitement definis, et que la structure 
du message soit parfaitement conforme, le message lui-meme (dans ce cas la reponse) ne peut pas 
etre « decode » sans application des regies du schema de codage SOAP 1.1. Concretement, il est 
impossible de reconstruire une structure partagee en memoire sans F application des regies de decodage. 

Appel 

GetCustomerRIBs est une interrogation (query) qui vise a obtenir tous les RIB des comptes des clients 
ayant comme nom de famille la valeur de l'argument 1 astName : 

POST /RentACar HTTP/1.1 

Host: webserver.bank.com 

Content-Type: text/xml ; charset="utf-8" 

Content-Length: nnnn 

SOAPAction: "http://webserver.bank.com/Account" 

<?xml version="1.0" encoding="UTF-8"?> 

<S0AP-ENV: Envelope xmlns:SOAP-ENV=" http://schemas.xml soap.org/soap/envel ope/" 
SOAP- ENV:encodingStyle=" http://schemas.xml soap.org/soap/encoding"> 
<SOAP-ENV:Body> 

<eb:getCustomerRIBs xmlns:eb="http://bank.org/encoded"> 

<lastName>Tartampion</lastName> 
</eb:getCustomerRIBs> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Retour 

Le resultat de 1'inteiTogation (return) est un tableau de customer, qui est une structure contenant, 
entre autres, un tableau de RIB : 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 

Content-Length: nnnn 

<?xml version="1.0" encoding="UTF-8"?> 
<S0AP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap. org/ soap/envelope/" 

SOAP- ENV:encodingStyle=" http://schemas.xml soap.org/soap/encoding"> 

<SOAP-ENV:Body> 

<eb:getCustomerRIBs Response xmlns:eb="http://bank.org/encoded"> 
<return> 
<customer> 

<f i rstName>Mathi eu</f i rstName> 

<1 astName>Tartampi on</l astName> 

<RIBs> 

<RIB id="RIB001"> 

<bankcode>4000K/bankcode> 



Technologies des services Web 

Deuxieme Partie 



<positioncode>00987</positioncode> 
<accountcode>0000123456A</accountcode> 
<control key>92</control key> 
</RIB> 
<RIB id="RIB002"> 

<bankcode>4000K/bankcode> 
<positioncode>00789</positioncode> 
<accountcode>0000654321B</accountcode> 
<control key>29</control key> 
</RIB> 
</RIBs> 
</customer> 
<customer> 

<f i rstName>Georgette</f i rstName> 

<lastName>Tartampion</lastName> 

<RIBs> 

<RIB href="#RIB001"/> 
<RIB href="#RIB002"/> 
</RIBs> 
</customer> 
</return> 
</eb:getCustomerRIBsResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Georgette et Mathieu Tartampion partagent deux comptes bancaires. La reponse utilise le mecanisme de 
referencement du style de codage SOAP 1 . 1 pour reduire sa taille. Voici la definition du type de RI B : 

<xs:group name="RIBTypeGroup"> 
<xs:sequence> 

<xs:element name="bankcode" type="xs:string"/> 
<xs:element name="positioncode" type="xs:string"/> 
<xs:element name="accountcode" type="xs:string"/> 
<xs:element name="control key" type="xs:string"/> 
</xs :sequence> 
</xs:group> 
<xs : complexly pe name="RIBStructType"> 

<xs:group ref="tns: RIBTypeGroup" minOccurs="0"/> 
<xs:attributeGroup ref="SOAP-ENC:commonAttributes"/> 
</xs:complexType> 

La presence de SOAP- ENC: common Attributes (id et href), lesquels sont definis dans le schema du style 
de codage SOAP 1.1 (voir le chapitre 8), permet de construire une structure de message valide du 
point de vue syntaxique pour un analyseur XML. En revanche, cette structure ne peut pas etre correc- 
tement decodee par le recepteur SOAP si elle n'est pas « semantiquement » interpretee en coherence 
avec les regies du style de codage. 
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Retourd'erreur 

Le retour d'erreur d'une invocation RPC est realise par un message d'erreur SOAP, sans contraintes 
particulieres, excepte le fait qu'un retour d'erreur ne peut pas contenir de valeur de retour, caracteristique 
propre a un retour d'appel reussi. 



Evolutions SOAP 1.2 (draft) 

SOAP 1 .2 propose des codes d'erreur additionnels (toujours dans I'espace de noms SOAP/RPC). 



Conclusion 

Dans les chapitres 7, 8 et 9 nous avons etudie en detail SOAP, le protocole d'echange d' election pour 
les services Web. 

Dans les premieres applications utilisant SOAP, les messages etaient construits « a la main », par un 
programme directement ecrit par le developpeur applicatif. Desormais, les outils de developpement 
et les moteurs d' execution permettent de faire l'economie de cette tache fastidieuse : le developpeur 
peut se consacrer a d'autres taches plus nobles, mais aussi autrement plus complexes, comme la 
conception d'une architecture d'interfaces WSDL et d'une architecture dynamique d'execution, en 
attendant que des outils encore plus evolues lui permettent de mettre en ceuvre des processus metier 
sophistiques impliquant un nombre important de services Web. 

SOAP reste cependant la technologie qui permet aux services Web de communiquer entre eux et avec 
leurs clients. Meme si le developpeur est aujourd'hui dispense de sa manipulation directe, il doit etre 
capable de comprendre un journal d'execution avec la trace des echanges (et il devra l'etre encore 
pendant quelques annees). En outre, la comprehension de la « philosophic » SOAP est indispensable 
pour maitriser 1' architecture generate et les differents « modules » de la technologie des services 
Web. 
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Decrire un service avec WSDL 



Le protocole SOAP permet d'echanger des messages entre differents processus. Mais comment peut-on 
formaliser les messages que les processus peuvent s'echanger ? De quelle maniere sont-ils decrits 
arm d'etre comprehensibles par chacun des processus qui interviennent dans Fechange ? Comment 
sont-ils transferes via 1' Internet ? Existe-t-il des logiciels pour gerer ces descriptions ? Ce sont ces 
questions qui vont etre etudiees dans le present chapitre. 

Une solution a cette problematique a ete proposee conjointement le 25 septembre 2000 par les societes 
Ariba, IBM et Mcrosoft. Ces trois entreprises, dont deux d' entre elles, IBM et Microsoft, etaient deja 
a Forigine du protocole de transport SOAP precedemment etudie, ont propose la specification WSDL 
(Web Services Description Language). Cette version 1.0 initiale de la specification a fait l'objet 
d'une evolution publiee le 23 Janvier 2001 : c'est cette derniere version, la 1.1, qui fait actuellement 
reference et qui a ete soumise a une normalisation le 15 mars 2001, sous forme d'une note, au W3C. 



Initiateurs 

Allaire, Ariba, BEA, Bowstreet, Commerce One, Compaq, DataChannel, Epicentric, Fujitsu Limited, Hewlett- 
Packard, IBM, Intel, I0NA Technologies, Jamcracker, Microsoft, Oracle, Rogue Wave, SAP, TIBCO Software, VeriSign, 
Vitria Technology, webMethods, XML Global Technologies et XMLSolutions constituent le groupe des initiateurs de 
ce projet. 



La solution WSDL, proposee par ce groupe de societes, repond a la problematique par l'approche de 
la description d'un service. Certains des processus qui participent a Fechange decrivent les types 
de messages qu'ils savent recevoir et consommer, et eventuellement ceux qu'ils sont susceptibles de 
produire et d'emettre, en reponse aux messages qu'ils recoivent. Ces processus se definissent comme 
des prestataires de services. L'ensemble des messages qu'ils decrivent represente Yinterface du 
service dont ils assurent la prestation. Les autres processus, clients de ces prestataires de services, 
peuvent entrer en communication avec eux sur la base de ces descriptions. 
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Ainsi, le terme de service Web apparait avec la specification WSDL. Ce langage permet de decrire des 
services echanges entre partenaires via F utilisation de standards Web (protocoles de transport, 
formats de message). 

La suite de ce chapitre s' appuie uniquement sur la version 1 . 1 de WSDL, la seule version utilisable et 
completement implemented a Fheure de la redaction de cet ouvrage. 

Cependant, le W3C precede actuellement a la conception de la version 1.2 suivante, dont un 
brouillon (draft) a ete publie le 24 Janvier 2003 (voir http://www.w3.org/TR/2003/WD-wsdl12-20030124). 
Cette standardisation est realisee dans le cadre du groupe de travail Web Services Description 
(voir http://www.w3c.org/2002/ws/desc), rattache a Factivite Web Services de F organisation (voir http:// 
www. w3c. org/2002/ws) . 

Precurseurs 

Cette specification est issue de la maturation de travaux anterieurs menes separement, notamment par 
IBM et Microsoft. Parmi ces travaux, on peut plus particulierement citer les projets : 

• NASSL (Network-Accessible Service Specification Language) d'IBM ; 

• SCL (SOAP Contract Language) de Microsoft ; 

• SDL (Service Descriptor Language) de Microsoft. 

Ces entreprises se sont ensuite reunies pour consolider les concepts ainsi experimented, afin de mettre 
au point et proposer une nouvelle specification commune. Cette specification s' appuie sur le format 
XML pour decrire des services reseau sous forme d'ensembles de nceuds de communication d'extre- 
mites (endpoints) qui traitent des messages contenant de Finformation orientee document ou orientee 
procedure. Les interactions (operations) et les messages font Fobjet d'une description abstraite. Ces 
derniers sont enfin associes par des liaisons (bindings) ou des couplages a des protocoles et a des 
formats de messages qui sont eux bien concrets. 

Ce langage de description de service est maintenu volontairement extensible afin de rendre possible 
la description de nceuds de communication d'extremites et des messages echanges entre les nceuds 
independamment des formats de message et des protocoles reseaux utilises in fine pour communiquer. 
Le document de specification decrit cependant les liaisons qui permettent de mettre en ceuvre des 
services Web definis en format WSDL en conjonction avec les protocoles SOAP 1.1 et HTTP GET/ 
POST ainsi que le format de donnees MIME. 

Cette premiere version de la specification est presentee comme une etape initiale vers la specification 
ulterieure de deux frameworks : 

• un premier framework de composition de services (assemblage et orchestration d'ensembles de 
services entre nceuds de communication) ; 

• un second/ramewor/: de description du comportement de ces memes services (regies de sequencement 
des envois et des receptions de messages entre nceuds de communication). 
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Principaux concepts 

La specification introduit quelques concepts essentiels a sa comprehension. Parmi ceux-ci, retenons 
les notions suivantes : 

• les types (types) : il s'agit de la definition des types de donnees qui structurent les messages, celle-ci 
repose sur un systeme de typage (tel que les schemas XML, par exemple) ; 

• les messages (messages) : ils represented une definition typee abstraite des donnees echangees entre 
les nceuds de communication ; 

• les operations (operations) : elles definissent la description abstraite d'ensembles coherents de 
messages (messages en entree, messages en sortie) qui forment les unites d'interaction avec le 
service Web ; 

• les types de ports (port types) : ils constituent des ensembles abstraits d' operations prises en charge 
par un ou plusieurs nceuds de communication ; 

• les liaisons (bindings) : elles decrivent les protocoles concrets et les formats de message pour 
chaque type de port ; 

• les ports (ports) : ce sont les nceuds de communication particuliers, chacun etant defini comme une 
combinaison entre une liaison et une adresse reseau ; 

• les services (services) : il s'agit de Fensemble des ports exposes pour permettre l'acces aux services 
correspondants. 

Les principes de base de cette construction, qui separe tres nettement la conception fonctionnelle d'un 
service (definition abstraite des interfaces) de son implementation (liaisons a des formats de message 
concret et a des protocoles de transport, deploiement sur le reseau), visent a rendre reutilisables : 

• les definitions abstraites des messages ; 

• les definitions abstraites des types de ports (et des operations qu'ils regroupent) ; 

• les definitions des liaisons associees a des protocoles et a des formats de message concret. 

Cette separation entre les aspects abstraits et concrets d'un service Web ainsi defini est tres importante 
et trouvera son illustration dans les deux chapitres suivants relatifs a la specification UDDI (Universal, 
Description, Discovery and Integration). 

De cette presentation des principaux concepts de la specification, il faut retenir qu'elle s'appuie, pour 
la description des donnees transportees dans les messages, sur un systeme de definition de types 
existants, sans chercher a en introduire un nouveau. En fait, WSDL fait appel en standard a la speci- 
fication XML Schema en tant que systeme de typage canonique, mais prevoit l'utilisation possible 
d'autres formalismes (extensibilite). 

L association des types de donnees, des messages et des operations avec les formats de message et les 
protocoles de transport est realisee par un mecanisme de « liaison » (binding). Ici encore, nous nous 
trouvons en presence d'une caracteristique destinee a favoriser 1' extensibilite de cette specification. 
En standard, WSDL decrit trois liaisons particulieres : 

• la liaison vers le protocole SOAP 1.1; 

• la liaison vers le protocole HTTP GET/POST ; 

• la liaison vers le format de donnees MIME. 
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Bien entendu, ces liaisons ne sont pas exclusives et d'autres liaisons peuvent etre cogues et formali- 
sees. Ces liaisons sont decrites via des extensions du langage WSDL. Elles s'appuient sur le noyau du 
langage WSDL que la specification definit comme un framework de definition de service. 



WSDL 1.1 etWS-l Basic Profile 1.0 

La premiere version du profil de base defini par le WS-I (Web Services Interoperability Organization) a adopte la 
specification WSDL, et plus particulierement la version 1.1, pour I'implementation de la description de services 
Web mis en ceuvre dans une architecture orientee services (voir chapitre 17, « Le defi de I'interoperabilite »). 
Les recommandations liees a I'usage de la specification WSDL sont definies dans la section « Service Description » 
(voir http://ws-i.Org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm#deschption) du draft de la version 1 .0 du profil 
de base, date du 8 octobre 2002. 

La portee des differentes recommandations emises est tres variable : certaines d'entre elles se bornent a preciser 
des points de la specification WSDL, d'autres a mieux separer les liens avec d'autres specifications (SOAP et XML 
Schema notamment) et enfin quelques recommandations rectifient certains exemples presentes dans la specification 
WSDL, voire en interdisent certaines possibilites (sur ce sujet, se reporter notamment a la remarque « Mise a I'ecart 
de I'encodage SOAP » du chapitre 17 : cette remarque concerne une recommandation relative a I'encodage des 
donnees dans les messages SOAP, mais introduit des implications au niveau WSDL, entre autres sur la liaison 
WSDL vers le protocole SOAP). 
Le profil de base precise qu'une instance de service Web doit etre decrite par une description de service WSDL 1 .1 . 



Structure d'un document WSDL 

Un document WSDL est tout d'abord un document XML. II peut etre represente schematiquement 
(voir figure 10-1). 



Figure 10-1 

Structure generate d'un document WSDL. 
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Dans cette structure, l'element racine est l'element definitions. Cet element peut comporter un 
attribut optionnel name : dans l'exemple decrit plus loin dans ce chapitre, ce document est nomme 

urn:GoogleSearch. 

Un document WSDL est constitue d'un ensemble d' elements definis par la specification. Selon les 
options de conception retenues pour decrire le(s) service(s), plusieurs ensembles distincts d'elements 
peuvent etre utilises, associes a des espaces de noms distincts (voir tableau 10-1). 

Tableau 10-1. Espaces de noms utilises dans un document WSDL 



Prefixe 


URI de I'espace de noms 


Description 


wsdl 


http://schemas.xmlsoap 
.org/wsdl/ 


Specifie I'espace de noms WSDL du framework de definition de service. 


soap 


http://schemas.xmlsoap. org/ 
wsdl/soap/ 


Specifie I'espace de noms WSDL en cas d'utilisation de la liaison WSDL 
SOAP (voir ci-apres la section consacree a cette liaison). 


http 


http://schemas.xmlsoap. org/ 
wsdl/http/ 


Specifie I'espace de noms WSDL en cas d'utilisation de la liaison WSDL 
HTTP GET/POST (voir ci-apres la section consacree a cette liaison). 


mime 


http://schemas.xmlsoap. org/ 
wsdl/mime/ 


Specifie I'espace de noms WSDL en cas d'utilisation de la liaison WSDL 
MIME (voir ci-apres la section consacree a cette liaison). 


soapenc 


http://schemas.xmlsoap. org/ 
soap/encoding/ 


Specifie I'espace de noms d'encodage decrit dans le protocole SOAP 1.1 
(voir ci-apres la section consacree a la liaison WSDL SOAP). 


soapenv 


http://schemas.xmlsoap. org/ 
soap/envelope/ 


Specifie I'espace de noms d'enveloppe decrit dans le protocole SOAP 1.1 
(voir ci-apres la section consacree a la liaison WSDL SOAP). 


xsi 


http://www. w3. org/2000/1 0/XML 
Schema-instance 


Specifie I'espace de noms instance decrit dans la specification XML Schema 
(si cette specification est utilisee pour definir les types de donnees). 


xsd 


http://www. w3. org/2000/1 01 
XMLSchema 


Specifie I'espace de noms schema decrit dans la specification XML Schema 
(si cette specification est utilisee pour definir les types de donnees). 


tns 


Divers 


Specifie, par convention, I'espace de noms propre au document WSDL 
(tns = this namespace). Defini par le concepteur du document. 




Divers 


Tout autre URI est considere comme dependant du contexte d'utilisation 
ou du programme utilisateur. 



Les espaces de noms decrits dans le tableau ne sont pas toujours presents dans les fichiers WSDL 
manipules. En effet, leur presence depend des liaisons definies dans le document ainsi que du 
systeme de typage des donnees retenu par le concepteur du service Web. 

Par exemple, dans le document presente dans la section suivante, les espaces de noms http://schemas 
.xmlsoap.org/wsdl/http/ et http://schemas.xmlsoap.org/wsdl/mime/ sont absents car les liaisons au protocole 
HTTP GET/POST et au format de donnees MIME ne sont pas utilisees par ce service Web ni utilisables 
pour y acceder. 

Exemple de document WSDL 

Le document expose ci-apres represente la description d'un nouveau service Web propose en 2002 
par le celebre moteur de recherche Google (voir http://www.google.com/apis). Cet exemple sera utilise 
plus loin dans le chapitre pour illustrer differents aspects de la specification WSDL. 
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<?xml version="1.0"?> 

<!-- WSDL description of the Google Web APIs. 

The Google Web APIs are in beta release. All interfaces are subject to 
change as we refine and extend our APIs. Please see the terms of use 
for more information. --> 

Definitions et espaces de noms utilises par le service : 

definitions name="urn:GoogleSearch" 

targetNamespace="urn:GoogleSearch" 

xmlns :typens="urn:GoogleSearch" 

xmlns :xsd=" http://www.w3.org/2001/XMLSchema" 

xmlns :soap=" http://schemas.xml soap.org/wsdl /soap/" 

xmlns :soapenc=" http://schemas.xml soap.org/soap/encoding/" 

xmlns :wsdl="http: / /schema s. xmlsoap.org/wsdl /" 

xmlns=" http://schemas.xml soap.org/wsdl /"> 

Definition des types de donnees utilisees dans les messages : 

<!-- Types for search - result elements, directory categories --> 
<types> 
<xsd: schema xmlns=" http://www.w3.org/2001/XMLSchema" 
targetNamespace="urn:GoogleSearch"> 

<xsd: compl exType name="Googl eSearchResul t"> 

<xsd:all> 

<xsd: element name="documentFiltering" type="xsd:boolean"/> 

<xsd:element name="searchComments" type="xsd:string"/> 

<xsd: element name="estimatedTotal ResultsCount" type="xsd:int"/> 

<xsd:element name="estimateIsExact" type="xsd:boolean"/> 

<xsd: element name=" result Elements" type= " ty pens : Result El ementAr ray" /> 

<xsd:element name="searchQuery" type="xsd:string"/> 

<xsd:element name="startlndex" type="xsd:int"/> 

<xsd:element name="endlndex" type="xsd:int"/> 

<xsd:element name="searchTips" type="xsd:string"/> 

<xsd: element name="di rectoryCategories" type="typens:Di rectoryCategory 

*»Array"/> 

<xsd:element name="searchTime" type="xsd:double"/> 

</xsd:all> 
</xsd: compl exType> 

<xsd: compl exType name=" Result El ement"> 

<xsd:all> 

<xsd:element name="summary" type="xsd:string"/> 

<xsd:element name="URL" type="xsd:string"/> 

<xsd:element name="snippet" type="xsd:string"/> 

<xsd:element name="title" type="xsd:string"/> 

<xsd:element name="cachedSize" type="xsd:string"/> 

<xsd: element name=" related Information Present" type="xsd:boolean"/> 

<xsd:element name="hostName" type="xsd:string"/> 

<xsd: element name="di rectoryCategory" type="typens:Di rectoryCategory "/> 

<xsd:element name="di rectoryTitle" type="xsd:string"/> 

</xsd:all> 



Decrire un service avec WSDL 

Chapitre 10 

</xsd: complexly pe> 
<xsd: complexly pe name=" Result El ementArray"> 
<xsd : compl exContent> 
<xsd: restriction base="soapenc:Array"> 

<xsd:attribute ref="soapenc:arrayType" wsdl :arrayType="typens:ResultElement[]"/> 
</xsd: restrict!' on> 
</xsd : compl exContent> 
</xsd: compl exType> 

<xsd: compl exType name="Di recto ryCategoryAr ray "> 
<xsd: compl exContent> 
<xsd: restriction base="soapenc:Array"> 
<xsd: attribute ref="soapenc:arrayType" 
wsdl :arrayType="typens:DirectoryCategory[]"/> 
</xsd: restrict!' on> 
</xsd: compl exContent> 
</xsd: compl exType> 

<xsd: compl exType name="Di recto ryCategory"> 
<xsd:all> 
<xsd:element name="ful 1 ViewableName" type="xsd:string"/> 

<xsd:element name="special Encoding" type="xsd:string"/> 

</xsd:all> 
</xsd:complexType> 
</xsd:schema> 
</types> 

Definition des messages mis en ceuvre dans les operations : 

<!-- Messages for Google Web APIs - cached page, search, spelling. --> 

<message name="doGetCachedPage"> 

<part name="key" type="xsd:string"/> 

<part name="url" type="xsd:string"/> 
</message> 
<message name="doGetCachedPageResponse"> 

<part name="return" type="xsd:base64Binary"/> 
</message> 
<message name="doSpel 1 ingSuggestion"> 

<part name="key" type="xsd:string"/> 

<part name="phrase" type="xsd:string"/> 
</message> 
<message name="doSpel 1 ingSuggestionResponse"> 

<part name="return" type="xsd:string"/> 
</message> 
<message name="doGoogl eSearch"> 

<part name="key" type="xsd:string"/> 

<part name="q" type="xsd:string"/> 

<part name="start" type="xsd:int"/> 

<part name="maxResul ts" type="xsd:int"/> 

<part name="fil ter" type="xsd:boolean"/> 

<part name="restrict" type="xsd:string"/> 

<part name="safeSearch" type="xsd:boolean"/> 
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<part name="lr" type="xsd:string"/> 

<part name="ie" type="xsd:string"/> 

<part name="oe" type="xsd:string"/> 
</message> 
<message name="doGoogl eSearch Response "> 

<part name="return" type="typens:GoogleSearchResul t"/> 
</message> 

Definition de F unique type de port et des operations associees : 

<!-- Port for Google Web APIs, "GoogleSearch" --> 
<portType name="Googl eSearchPort"> 
<operation name="doGetCachedPage"> 

<input message="typens:doGetCachedPage"/> 

<output mess age="ty pens :doGetCachedPageResponse"/> 
</operation> 
<operation name="doSpel 1 ingSuggestion"> 

<input message="typens:doSpel 1 ingSuggestion"/> 

<output message="typens:doSpel 1 ingSuggestionResponse"/> 
</operation> 
<operation name="doGoogleSearch"> 

<input message="typens:doGoogleSearch"/> 

<output mess age="ty pens :doGoogleSearch Response "/> 
</operation> 
</portType> 

Definition de V unique liaison vers un protocole de transport, SOAP dans le cas present : 

<!-- Binding for Google Web APIs - RPC, SOAP over HTTP --> 
<binding name="GoogleSearchBinding" type="typens: GoogleSearch Port "> 
<soap:binding style="rpc" 

transport^" http://schemas.xml soap.org/soap/http"/> 
<operation name="doGetCachedPage"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

namespace^" urn: GoogleSearch" 

encodingStyle= "http://schemas.xml soap. org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 

namespace^" urn: GoogleSearch" 

encodingStyle= "http://schemas.xml soap. org/soap/encoding/"/> 
</output> 
</operation> 

<operation name="doSpel 1 ingSuggestion"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

namespace^" urn: GoogleSearch" 

encodingStyle=" http://schemas.xmlsoap.Org/soap/encoding/V> 
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</input> 
<output> 
<soap:body use="encoded" 

namespace="urn:GoogleSearch" 

encodingStyle= "http://scheinas.xml soap. org/soap/encoding/"/> 
</output> 
</operation> 

<operation name="doGoogleSearch"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

namespace="urn:GoogleSearch" 

encodingStyle= "http://schemas.xml soap. org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 

namespace="urn:GoogleSearch" 

encodingStyle= "http://schemas.xml soap. org/soap/encoding/"/> 
</output> 
</operation> 
</binding> 

Definition du service et de son point d'acces coiTespondant : 

<!-- Endpoint for Google Web APIs --> 
<service name="GoogleSearchService"> 
<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> 

<soap: address location="http://api .google. com/sea rch/beta2"/> 
</port> 
</service> 
</definitions> 

Noms et liens entre fragments de documents 

A l'element racine def i ni ti ons du document WSDL peut etre associe un espace de noms particulier 
optionnel via l'attribut targetNamespace. Dans notre exemple, cet attribut est fixe a la valeur 
urn:GoogleSearch. Les generateurs de documents WSDL le fixent generalement a une valeur qui 
debute par la constante http://tempuri.org/pai defaut. Le concepteur du document doit ensuite le modifier 
pour le rendre particulier a ce document. Cet attribut est de type URI et doit etre obligatoirement absolu. 

II est possible d' importer un ou plusieurs fragments de documents dans un document WSDL. Cela est 
realise via l'utilisation de la balise import de la maniere suivante : 

I definitions .... > 
<import namespace="ur7" location="t/r7'"/> 
</definitions> 
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Chacun des fragments importes peut etre associe a un espace de noms particulier via l'attribut name- 
space. Tous les elements de cette collection de definitions peuvent etre importes : service, port, 
message, liaison et type de port. 

Chacun de ces elements peut done etre reference a Finterieur du document WSDL. Chaque reference 
est effectuee en utilisant un nom qualifie. Le mecanisme de resolution des noms qualifies est similaire 
a celui de la specification XML Schema. 

Cette faculte d'importation de fragments de definitions est tres importante et offre un mecanisme 
simple de reutilisation de definitions de services. L'exemple de Google n'utilise pas cette possibilite. 
En revanche, le document de la specification WSDL fournit un exemple d'importation a trois niveaux 
(voir la section 2.1.2 : « Authoring Style » : http://www.w3c.Org/TR/2001/NOTE-wsdl-20010315#_style), tire 
de la desormais tres mediatique illustration de la cotation d' actions (Stock Quote Service) : 

• Un premier document est constitue du schema XML qui decrit les types de donnees manipulees 
par les messages associes a ce service : ce document est localise par FURL http://example.com/stock- 
quote/stockquote.xsd et son espace de noms propre (attribut targetNamespace) est identifie par FURI 
http://example.com/stockquote/schemas. 

• Un second document localise par FURL http://example.com/stockquote/stockquote.wsdl, dont Fespace de 
noms propre est http://example.com/stockquote/definitions, fournit la definition abstraite d'une operation 
de recherche de la valeur courante d'une action passee en parametre (GetLastTradePrice). Cette 
definition s'appuie sur des messages qui manipulent les types de donnees definis dans le premier 
document. Le schema XML est done importe et son espace de noms http://example.com/stockquote/ 
schemas est associe au prefixe xsdl, via une declaration xmlns : les donnees manipulees par les 
messages definis dans ce second document referencent ainsi les types definis dans le premier document. 

• Le troisieme document est celui qui permet d'exposer F implementation concrete du service. Ce 
document, localise par FURL http://example.com/stockquote/stockquoteservice.wsdl, definit d'une part la 
liaison de Foperation GetLastTradePrice decrite dans le second document au protocole de trans- 
port SOAP et d' autre part Fadresse Internet d'acces au service. Le second document est done 
importe et son espace de noms http://example.com/stockquote/definitions est associe au prefixe def s, via 
une declaration xmlns : Fassociation entre le type de port qui definit Foperation decrite dans le 
second document et la liaison definie dans le troisieme document est realisee via Futilisation de 
l'attribut type de Felement binding dont la valeur est ici StockQuotePortType. 

A Futilisation, le consommateur final d'un tel service ne doit acceder directement qu'au dernier 
document qui lui fournit Fadresse d'acces au service. Cependant, les deux premiers documents 
doivent etre disponibles au moment de Faeces a ce service : en cas d'indisponibilite de Fun d' entre 
eux, la validation du document WSDL ne pourra pas etre realisee et la generation d'un proxy-service 
dynamique sera tout simplement impossible. 

Cette decomposition de la definition d'un service et la souplesse permise en phase de re-assemblage par 
F intermediate du mecanisme d'importation offrent de nombreuses possibilites comme nous venons 
de le voir. 
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La specification UDDI, etudiee dans les deux chapitres suivants, fait largement appel a cette capacite. 
En effet, la definition, la diffusion et la promotion de F equivalent des deux premiers documents definis 
precedemment peuvent relever de Fautorite d'une entite de normalisation ou d'un organisme profes- 
sionnel (les autorites boursieres dans notre exemple), tandis que la definition, la diffusion et la 
promotion du troisieme document sont du ressort des entreprises ou associations qui offrent un acces 
a ce service, comme les banques ou les sites Web de bourse en ligne. Dans le modele UDDI, les deux 
premiers documents representent un « service type » (tModel), alors que le troisieme document 
constitue un « modele de liaison » (Binding Template) qui permet de relier le service type abstrait a 
un « service metier » concret {Business Service). 



Recommandations WS-I Basic Profile 1.0 (draft) 

Recommandation R2001 : une description WSDL ne doit importer une autre description WSDL que par I'usage de 

labalise import deWSDL. 

Recommandation R2002 : une description WSDL ne doit importer une description XML Schema que par I'usage 

de la balise import de XML Schema. 

Recommandation R2003 : une description WSDL ne doit utiliser la balise import de XML Schema qu'a I'interieur 

de I'element schema de I'element types WSDL. 

Recommandation R2004 : une description WSDL n'utilisera pas la balise import de XML Schema pour importer 

une definition XML Schema incluse dans une autre description WSDL. 



Ces quatre recommandations WS-I ont pour objectif de reserver I'usage des differentes balises 
d' importation dans leurs domaines respectifs de specification. L' application de ces recommandations 
fait que les exemples d' importation decrits dans la specification WSDL que nous venons de voir ne 
sont plus corrects et doivent etre recrits. 

L importation initiale du premier fichier (schema XML) dans le deuxieme fichier (description WSDL 

abstraite) : 



<import namespace=" http://example.com/stockquote/schemas" 

location="http: //example. com/ stockquote/s toe kquote.xsd"/> 



I 

doit etre remplacee par : 



<types> 

<xsd: schema xmlns:xsd=" http://www.w3.org/2001/XMLSchema"> 

<xsd: import namespace=" http://example.com/stockquote/schemas" 

schema Location="http:/ /example. com/ stockquote/s toe kquote.xsd"/> 
</xsd:schema> 
</types> 

En revanche, l'importation initiale du deuxieme fichier (description WSDL abstraite) dans le troisieme 
fichier (description WSDL concrete) est toujours correcte et ne necessite pas de modification : 

I<import namespace=" http://example.com/stockquote/definitions" 
location=" http://example.com/stockquote/stockquote.wsdl "/> 
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RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R4002 : la specification XML autorise I'encodage UTF-8 a incorporer une marque de polarite BOM 

(Byte Order Mark) Unicode. Un processeur WSDL doit etre pret a I'accepter (voir les problemes d'interoperabilite 

exposes dans la section « SOAP Builders Round I » du chapitre 17 : « Le defi de I'interoperabilite »). 

Recommandation R2005 : la valeur de I'attribut targetNamespace de I'element defini ti ons d'une description WSDL 

importee doit correspondre a la valeur de I'attribut targetNamespace de I'element import de la description 

WSDL qui I'importe. 

Recommandation R2007 : une description WSDL doit specifier la valeur de I'attribut 1 ocati on de I'element 1 mport. 

Recommandation R2008 : la valeur de I'attribut location de I'element import doit etre comprise comme un 

guide (hint). La raison d'etre de cette recommandation est peu claire, notamment par rapport a la precedente 

recommandation (R2007). 

Recommandation R2020 : I'element documentati on peut apparaitre sous I'element import dans une description 

WSDL. 

Recommandation R2021 : I'element documentation peut apparaitre sous I'element part dans une description 

WSDL. 

Recommandation R2022 : I'element types doit apparaitre comme le premier enfant de I'element definitions 

dans une description WSDL, s'il n'y a pas d'element import, ou immediatement derriere I'element import s'il 

existe. 

Recommandation R2023 : dans une description WSDL, les elements import, s'ils existent, doivent apparaitre 

comme les premiers enfants de I'element defi ni ti ons. 



Elements de definition 

Chacun des elements d'une definition WSDL peut etre decrit via 1' utilisation du sous-element 
documentati on. Cet element optionnel, qui peut etre constitue par du texte ou d'autres elements, permet 
ainsi de documenter la description d'un service. 

Les types de donnees 

L' element types du document WSDL contient la description des types de donnees manipulees dans 
les messages. 

La specification XML Schema constitue le systeme canonique de typage des donnees de la specification 
WSDL. Cependant, cette specification prevoit F utilisation possible d'autres systemes de typage de 
donnees. En effet, le schema XML des documents WSDL definit I'element types de la maniere 
suivante : 

<element name="types" type="WSDL (Web Services Description Language) :typesType"/> 
<complexType name="typesType"> 
<complexContent> 

<extension base="WSDL (Web Services Description Language) :documented"> 
<sequence> 

<any namespace="#other" minOccurs="0" maxOccurs="unbounded"/> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 
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Le schema XML est ici etendu via F utilisation de 1' element generique any auquel est associe un 
espace de noms ##other : un element d'extensibilite WSDL, comparable a l'element schema de la 
specification XML Schema, peut done etre introduit sous l'element WSDL types et permettre ainsi 
d'identifier un systeme de typage non canonique. 

Cet element types est situe directement sous la racine dans la hierarchie du document WSDL : 

definitions .... > 
<types> 

<schema ... /> 

</types> 

</definitions> 

Dans l'exemple Google, le schema XML definit cinq types de donnees complexes. 

Les schemas XML sont utilises independamment du fait que le format de donnees utilise in fine dans 
les instances de messages soit XML ou non. Dans cette situation, la specification propose certaines 
recommandations a respecter pour Fencodage des types abstraits concernes : 

• Utiliser des elements plutot que des attributs d'element. 

• Ne pas introduire d'elements ou d' attributs qui entrainent une adherence au protocole de transport 
ou au format de donnees sous-jacent et qui denaturent F abstraction necessaire des messages 
concernes. 

• Lextension du type Array defini dans le schema d'encodage SOAP 1.1 (voir espace de noms http:/ 
/schemas.xmlsoap.org/soap/encoding/) est recommandee pour les types tableau. Ces types doivent etre 
nommes KrrayOfXXX, ou XXX correspond au type des elements du tableau represente (<compl exType 
name="ArrayOfstring">, par exemple). Le type des elements du tableau et les dimensions du 
tableau sont precises par F attribut d'encodage SOAP a r rayTy pe. Cet attribut est redefini dans Fespace 
de noms WSDL pour suppleer a un manque de la specification XML Schema. Pour le tableau de 
type string, on trouvera cet attribut exprime sous la forme attribute ref="soapenc:arrayType" 
wsdl :arrayType="string[]"/>, par exemple. Dans l'exemple Google, le type complexe ResultEle- 
mentArray represente un tableau a une dimension d'elements de type complexe ResultElement 
defini dans Fespace de noms propre au service Web de Google (URN:GoogleSearch). La defini- 
tion correspondante du type complexe est ainsi codee : 

<xsd : compl exType name="Resul tEl ementArray"> 
<xsd:complexContent> 
<xsd: restriction base="soapenc:Array"> 

<xsd:attribute ref="soapenc:arrayType" wsdl :arrayType="typens:ResultElement[]"/> 
</xsd:restriction> 
</xsd: compl exContent> 
</xsd: compl exType> 

Utiliser le type de donnees XML Schema anyType lorsqu'un champ peut etre de type indetermine. 
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RecommandationsWS-l Basic Profile 1.0 (draft) 

Le profil de base exige I'usage d'XML Schema en tant que systeme de typage des donnees (il restreint done les 

possibility de WSDL). 

Recommandation R2101 : une description WSDL ne doit pas utiliser des references qualifies (Qname) a des 

types dont I'espace de noms n'est pas importe. 

Recommandation R2110 : une description WSDL ne doit pas utiliser I'attribut soapenc:arrayType. Cette 

recommandation contredit ce que la specification WSDL propose et que nous venons juste d'evoquer ci-avant. 

Recommandation R2800 : les descriptions WSDL peuvent utiliser toutes les constructions permises par XML 

Schema 1.0. 



Pour se conformer a la regie 2110, les types de donnees utilisees par le service GoogleSearch, en lieu 
et place de la specification originale de Google, pourraient etre importes a partir d'un schema XML 
exprime de la maniere suivante : 

<?xml version="1.0"?> 
<xsd: schema 

t a rgetNamespace=" urn: GoogleSearch" 
xmlns:tns=" urn: GoogleSearch" 
xmlns:xsd=" http://www.w3.org/2001/XMLSchema"> 
<xsd: complexly pe name="GoogleSearchResult"> 
<xsd:all> 

<xsd: element name=" document Fil tering" 
<xsd: element name="searchComments" 
<xsd: element name="estimatedTotal Resul tsCount 
<xsd: element name=" estimate Is Exact" 
<xsd: element name=" result Elements" 
<xsd: element name="searchQuery" 
<xsd:element name="startlndex" 
<xsd:element name="endlndex" 
<xsd: element name="searchTips" 
<xsd: element name="di rectory Categories" 
<xsd: element name="searchTime" 
</xsd:all> 
</xsd:complexType> 

<xsd: complexly pe name=" Resul tElementArray"> 
<xsd:sequence> 

<xsd:element ref="tns:ResultElement" maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 

<xsd: complexly pe name=" Result El ement"> 
<xsd:all> 

<xsd:element name="summary" type="xsd:string"/> 

<xsd:element name="URL" type="xsd:string"/> 

<xsd:element name="snippet" type="xsd:string"/> 

<xsd:element name="title" type="xsd:string"/> 

<xsd:element name="cachedSize" type="xsd:string"/> 

<xsd: element name="rel atedInformationPresent"type="xsd:boolean"/> 

<xsd:element name="hostName" type="xsd:string"/> 



type="xsd: boolean "/> 

type="xsd:string"/> 

type="xsd:int"/> 

type="xsd: boolean "/> 

type="tns: Result El ementArray"/> 

type="xsd:string"/> 

type="xsd:int"/> 

type="xsd:int"/> 

type="xsd:string"/> 

type="tns:DirectoryCategoryArray"/> 

type="xsd:double"/> 
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<xsd: element name=" directory Category" type="tns:DirectoryCategory"/> 
<xsd:element name="directoryTitle" type="xsd:string"/> 
</xsd:all> 
</xsd:complexType> 

<xsd:complexType name="DirectoryCategoryArray"> 
<xsd:sequence> 

<xsd: element ref="tns:DirectoryCategory" maxOccurs=" unbounded "/> 
</xsd:sequence> 
</xsd:complexType> 

<xsd:complexType name="DirectoryCategory"> 
<xsd:all> 

<xsd:element name="full ViewableName" type="xsd:string"/> 
<xsd:element name="special Encoding" type="xsd:string"/> 
</xsd:all> 
</xsd: complexly pe> 
</xsd:schema> 

Cette maniere de faire permet ainsi de remplacer les tableaux SOAP par des tableaux XML Schema 
et de revenir a une representation litterale, hors du style de codage SOAP 1.1. Les deux tableaux 
ResultElementArray et DirectoryCategoryArray, qui faisaient appel a 1'attribut soapenc:arrayType, 
sont maintenant en phase avec la regie R2110 du profil de base WS-I. II ne reste plus qu'a modifier 
l'element types de la description WSDL et a le remplacer par ce nouvel element qui realise l'importation 
du nouveau schema XML (l'URI du schema est bien entendu purement fictif) : 

<types> 

<xsd: schema xmlns:xsd=" http://www.w3.org/2001/XMLSchema"> 
<xsd: import names pace=" urn :GoogleSearch" 
schemaLocation= 

"http://api .google. com/sea rch/beta2/ty pes /GoogleSearch.xsd"/> 
</xsd:schema> 
</types> 

Apres cette modification (notons sa conformite a plusieurs des recommandations WS-I etudiees 
precedemment), le prefixe soapenc peut etre retire de l'element def i ni ti ons de la description WSDL, 
car il n'a plus de raison d'etre. Pour etre complet, il convient egalement de reexaminer l'usage des 
attributs use et encodingStyle dans les liaisons : ils sont eux aussi soumis a des recommandations 
particulieres du WS-I, lesquelles sont presentees plus loin dans ce chapitre. 

Les messages 

Un message represente une unite logique d'echange d' information. II est constitue d'un ensemble de 
parties logiques (parts). Chacune de ces parties est associee au type de son contenu, lequel est defini 
dans l'element types. 

Les elements message sont situes directement sous l'element racine du document WSDL : 

definitions .... > 

<message name=" nmtoken"> 

<part mme=" runtoken" element="gname"? type="gnaffle"?/> 

</message> 

</definitions> 
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Le nom d'un message est unique dans F ensemble des noms des messages definis dans le document. 

Les attributs d'une partie de message peuvent etre etendus au titre de l'extensibilite de WSDL. La 
specification definit uniquement les attributs name, el ement et type : 

• l'attribut name est unique parmi les parties du message : la partie maxResul ts du message doGoogl e- 
Search par exemple ; 

• l'attribut el ement reference un element de schema XML par un nom qualifie ; 

• 1' attribut type reference un s i mpl eType ou un compl exTy pe de schema XML par un nom qualifie : par 
exemple, la valeur typens:GoogleSearchResult de l'attribut type du message GoogleSearchResult 
reference le type complexe Googl eSearchResul t du schema XML du service Web de Google. 

Les parties de message sont utiles pour definir les contenus logiques abstraits d'un message et permettre 
ainsi de les reference! - directement par les elements de liaison. 



Recommandations WS-I Basic Profile 1.0 (draft) 

Recommandation R2201 : si l'attribut style est fixe a la valeur document et si l'attribut use est fixe a la valeur 

1 iteral dans une liaison SOAP, alors la description WSDL doit comporter au plus une partie dans I'element 

message qui constitue I'element d'extension soap: body (voir plus loin la section « L'element d'extensibilite SOAP 

body »). 

Recommandation R2202 : si l'attribut styl e est fixe a la valeur rpc et si l'attribut use est fixe a la valeur 1 iteral 

dans une liaison SOAP, alors la description WSDL peut ne comporter aucune partie dans I'element message qui 

constitue I'element d'extension soap: body (voir plus loin la section « L'element d'extensibilite SOAP body »). 

Recommandation R2203 : si l'attribut styl e est fixe a la valeur rpc et si l'attribut use est fixe a la valeur 1 iteral 

dans une liaison SOAP, alors la description WSDL doit utiliser l'attribut type pour definir les parties de I'element 

message. 

Recommandation R2204 : si l'attribut style est fixe a la valeur document et si l'attribut use est fixe a la valeur 

literal dans une liaison SOAP, alors la description WSDL doit utiliser l'attribut element pour definir les parties 

de I'element message. 

Recommandation R2205 : lorsque, dans une description WSDL, l'attribut element est utilise pour definir une 

partie d'un element message, la valeur de l'attribut el ement doit referencer une definition d'element. 



Les types de ports 

Le type de port definit un ensemble d'operations abstraites et indique les messages impliques dans 
ces operations. Cet element se situe comme suit dans la hierarchie du document WSDL : 

definitions .... > 

<portType name="nmtoken"> 

<operation name="nmtoken" ... /> 

</portType> 

</definitions> 
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Une operation est un ensemble de messages qui constitue une unite d' interaction (transmission 
primitive) avec le service Web. La specification WSDL prend en charge quatre types d' operations : 

• F interaction a sens unique ; 

• la requete/reponse ; 

• la demande de reponse ; 

• la notification. 

Seules les liaisons vers les deux premiers types d' operations sont definies par la specification WSDL. 

Interaction a sens unique 

L interaction a sens unique correspond a une situation ou le nceud de communication ne fait que 
receptionner un message : 

I<operation name="nmtoken"> 
<input name="nmtoken"? message="qname"/> 
</operation> 

Interaction de type requete/reponse 

L interaction de type requete/reponse est mise en ceuvre lorsque le nceud de communication recoit un 
message et renvoie une reponse correlee. Cette configuration s'exprime ainsi : 

<operation name="nmtoken" parameterOrder="nmtokens"> 

<input name="nmtoken"? message="qname"/> 

<output name="nmtoken"? message="qname"/> 

<fault name="nmtoken" message="qname"/>* 
</operation> 

Cette description de 1' operation ne prejuge pas de la methode de correlation entre le message input et 
le message output qui sera utilisee (mise en ceuvre d'un protocole de transport synchrone ou asyn- 
chrone). Cette methode sera precisee dans chaque liaison au(x) protocole(s) reel(s) de communication 
utilise(s). Les elements fault optionnels (sens donne au caractere « * » dans la notation utilisee par 
la specification WSDL) specifient le format abstrait des messages d'erreur eventuellement produits 
par ce type d' interaction. 

L'exemple du service Web Google definit un seul type de port nomme Googl eSearchPort qui comprend 
trois operations : doGetCachedPage, doSpellingSuggestion et doGoogleSearch, lesquelles prennent toutes 
en charge des interactions de type requete/reponse. 

Interaction de type demande de reponse 

Une interaction de type demande de reponse correspond a une situation ou le nceud de communication 
emet un message et attend une reponse a cette requete. Cette configuration peut etre decrite ainsi : 

<operation name="nmtoken" parameterOrder="nmtokens"> 

<output name="nmtoken"? message="qname"/> 

<input name="nmtoken"? message="qname"/> 

<fault name="nmtoken" message="qname"/>* 
</operation> 
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De meme, les considerations sur la methode de correlation entre les messages, valables pour les inter- 
actions de type requete/reponse, s'appliquent aussi a ce type d' operation : cette particularite sera 
precisee dans la liaison au(x) protocole(s) reel(s) de communication utilise(s). Ici encore, des elements 
fault optionnels specifient le format abstrait des messages d'erreur eventuellement produits par ce 
type d' interaction. 

Interaction de type notification 

Enfin, une interaction de type notification correspond a une situation dans laquelle le nceud de 
communication n'emet qu'un message de type output tel que : 

I<operation name="nmtoken"> 
<output name="nmtoken"? message="qname"/> 
</operation> 

Nommage et portee des elements d'une operation 

Le nommage des elements input et output est unique a l'interieur d'un type de port. La specification 
prevoit un nommage par defaut selon les types d'operations : 

• en ce qui concerne les interactions de type sens unique ou notification, les elements 1 nput ou output 
non nommes explicitement prennent le nom de F operation qu'ils prennent en charge par defaut ; 

• pour ce qui touche aux interactions qui mettent en ceuvre des messages 1 nput et output (interactions 
de type requete/reponse ou demande de reponse), les elements i nput ou output non nommes expli- 
citement prennent par defaut le nom de F operation qu'ils prennent en charge, suffixe respectivement 
par les chaines de caracteres Request, Sol i ci t ou Response. 

Quant a la portee des noms d'elements f aul t, celle-ci est limitee a une unicite a l'interieur d'une meme 
operation. 

Ordre des parametres d'un message pour une operation 

L'ordre des parametres dans une operation peut etre specifie de maniere optionnelle. II peut se reveler 
utile pour des echanges de type RPC (Remote Procedure Call ou, en francais, appel de procedure 
distante) de specifier la signature de la procedure appelee. Les interactions de type requete/reponse 
ou demande de reponse peuvent (may) done preciser la liste des noms de parametres via Fattribut 
parameterOrder en fournissant Fensemble ordonne des noms de parties de message separes par une 
espace. Cette liste est soumise a quelques regies : 

• l'ordre des noms de parties de message doit respecter l'ordre des parametres de la signature RPC 
de la procedure ; 

• si un nom de partie apparait a la fois dans un message input et output, il s'agit d'un parametre de 
type in/out ; 

• si un nom de partie apparait uniquement dans un message 1 nput, il s'agit d'un parametre de type i n ; 

• si un nom de partie apparait uniquement dans un message output, il s'agit d'un parametre de type out ; 

• le resultat de l'appel de la procedure n'est pas fourni dans cette liste. 
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Cette information est facultative, meme pour les echanges de type RPC. Lorsqu'elle est presente, elle 
ne doit etre considered que comme une donnee indicative (hint). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2301 : 1'ordre des parties d'un element message dans une description WSDL doit correspondre 
a I'ordre definitif des elements part dans une instance de message SOAP correspondante (on the wire). 
Recommandation R2302 : une description WSDL peut utiliser I'attribut parameterOrder d'un element opera- 
tion pour specifier la valeur de retour et les signatures de methode en tant que guide pour des generateurs de 
code. 

Recommandation R2303 : une description WSDL ne doit pas utiliser d'interactions de type demande de reponse 
ou notification : ces deux possibilites, pourtant permises par la specification WSDL, sont done expressement interdites 
par I'organisation WS-I. 

Recommandation R2304 : toutes les operations definies dans un type de port doivent etre identifies par des 
valeurs distinctes de I'attribut name. 

Recommandation R2305 : les operations definies dans un type de port de style rpc doivent comporter au plus un 
element part dans I'element message qui contient le resultat de I'appel. Cet element part peut cependant 
representor un type complexe. 



Les liaisons 

La description de la relation entre les operations definies dans un type de port et les protocoles et 
formats de message qui prendront en charge les echanges ainsi definis est effectuee par l'interme- 
diaire de la definition d'elements de liaison. La structure generique de ces elements de liaison est 
representee de la maniere suivante : 

<binding name="nmtoken" type="qname"> 
<operation name="nmtoken"> 

<input name="nmtoken"> 

</input> 

<output name="nmtoken"> 

</output> 

<fault name="nmtoken"> 

</fault> 
</operation> 
</binding> 

Comme nous l'avons vu precedemment, les elements input et output sont presents ou non selon le 
type d'interaction mis en ceuvre par l'operation. De meme, les elements fault eventuels ne sont 
presents que pour les interactions de type requete/reponse ou demande de reponse. Le document 
WSDL peut specifier differentes liaisons : aussi l'unicite du nom de liaison est-elle obligatoire. Le 
lien avec le type de port pris en charge par la liaison est indique via I'attribut type de la liaison. 

Le nommage d'une operation n'est pas forcement unique. Aussi faut-il preciser egalement le nom de 
I'element input ou output qui en depend pour identifier l'operation que Ton souhaite utiliser sans 
ambiguite. Cela est suffisant car le nommage des elements input et output est unique a l'interieur du 
type de port reference par la liaison. 
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A chaque niveau de ce sous-arbre XML peuvent etre ajoutes des elements d'extensibilite qui permettent 
de preciser finement les interactions entre les elements descriptifs abstraits et la grammaire prise en 
charge par les protocoles et formats de message concret. 

Deux regies importantes peuvent etre retenues : 

• une liaison ne peut mettre en ceuvre qu'un et un seul protocole ; 

• aucun URI ne doit etre reference dans une liaison. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2401 : une description WSDL ne doit utiliser que la liaison SOAP telle qu'elle est decrite dans la 
specification WSDL 1.1 a la section 3 « SOAP Binding » (voir httpJ/www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap-b). 
Lorsque la version 1 .2 de WSDL sera disponible et implementee, elle ne pourra etre utilisee dans le cadre de cette 
version du profil. Dans cette optique, une nouvelle version du profil sera vraisemblablement introduite par le WS-I. 



Les ports 

Un port definit un nceud de communication, et done un URI, pour une liaison particuliere. Dans un 
document WSDL, cet element se decrit ainsi : 

<port name="nmtoken" binding="qname"> 
</port> 

La portee du nommage d'un port s'etend a Fensemble du document WSDL dans lequel il est decrit. 
La liaison associee a ce port est reperee via Fattribut binding du port. Des elements d'extensibilite 
peuvent etre ajoutes sous l'element port. 

A cet element s'appliquent egalement deux regies importantes : 

• un port ne doit pas comporter plus d'un URI ; 

• aucune information de liaison autre qu'une adresse ne peut etre fournie. 

Dans notre exemple, le service Web nomme GoogleSearchService propose un port nomme Google- 
SearchPort, associe a la liaison nominee GoogleSearchBinding. Ce port correspond au point d'acces 
Internet http://api.google.com/search/beta2 offert par Google : 

<service name= "GoogleSearchService") 

<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> 
<soap: address location="http://api . google. com/sea rch/beta2"/> 

</port> 
</service> 

Les services 

Un service est materialise dans un document WSDL de la maniere suivante : 

|<service name="nmtoken"> 
<port .... /> 
</service> 

Comme pour le port, la portee du nommage d'un service s'etend a l'ensemble du document WSDL. 
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Un service peut regrouper plusieurs ports. Dans cette situation, les ports ne peuvent communiquer 
entre eux, c'est-a-dire que la sortie d'un port ne peut constituer F entree d'un autre port. Un meme 
type de port peut etre desservi par des ports differents, soit du fait d'un URI different, soit via F utili- 
sation de liaisons differentes. Dans ce cas, les ports sont considered comme alternatifs et offrent la 
meme interface abstraite (equivalence semantique). Cette situation peut se presenter dans une situa- 
tion ou un meme service peut etre atteint en intranet ou par Internet selon la position occupee par 
F application cliente de ce service. 

De meme qu'il est possible de choisir le port a utiliser en fonction des caracteristiques reseau et des 
couches de transport, F application cliente du service peut etre amenee a selectionner le port selon 
des criteres plus abstraits, etablis en fonction de la tache a accomplir. En effet, un service peut fournir 
un ensemble d'operations, par Fintermediaire des regroupements effectues dans les types de ports, 
plus ou moins coherent et complet par rapport aux besoins de F application cliente. De ce fait, ce 
programme peut etre amene a realiser une analyse de second niveau arm de determiner le service ou 
le port a Finterieur d'un meme service apte a couvrir le mieux possible ses besoins. 

La mise en oeuvre de ports alternatifs 

Imaginons, par exemple, la situation d'un visiteur medical qui utilise un systeme de prise de 
commandes, soit a Finterieur des locaux de son entreprise, soit en clientele ou directement de chez 
lui avant ou apres son circuit de visites. II devient tout a fait possible d'utiliser une seule et meme 
application qui se connecte indifferemment au meme service de prise de commandes, quelle que soit 
sa position geographique et reseau (Internet ou intranet). 

II suffit que cette application soit capable de selectionner le port adapte en fonction du contexte : dans 
notre exemple, un acces a partir d'Internet pourra s'effectuer par une liaison qui met en oeuvre le 
protocole SOAP ou HTTP GET/POST. 

En revanche, si Faeces est realise a partir d'un intranet et que le service de prise de commandes 
fonctionne sur un serveur d'applications Java, le programme client de l'application peut se connecter 
par une liaison qui specifie Faeces via les protocoles Java/RMI ou Corba/IIOP, ou eventuellement de 
maniere asynchrone par Fintermediaire d'une file d'attente JMS par exemple. 

Bien entendu, cette ubiquite trouve ses limites dans celles auxquelles sont soumis les protocoles et 
les formats de message eux-memes sous-jacents. 

Liaisons standards 

La specification WSDL decrit deux liaisons standards a des protocoles de transport : 

• la liaison avec le protocole SOAP ; 

• la liaison avec le protocole HTTP GET/POST. 

Elle precise egalement la liaison au format de message MIME. 

Ces protocoles et formats de message ne sont bien entendu pas exclusifs, et peuvent etre completes par 
d'autres protocoles et formats via le mecanisme d' extension et Futilisation d'elements d'extensibilite 
places a des positions bien precises du document WSDL comme nous Favons vu precedemment. 
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La liaison decrit comment sont associes ces protocoles et formats de message aux abstractions que 
sont les messages, les operations et les types de port que nous venons d'etudier. L' utilisation de ces 
elements d'extensibilite dans le cadre des liaisons n'est pas exclusive (extension possible dans le 
cadre de la gestion de la qualite de service, de la coordination et la correlation de messages, de 
la gestion de transactions...)- Les differents points d'accroche des elements d'extensibilite dans la 
structure d'un document WSDL sont prevus par la specification (voir tableau de la specification : 
http://www. w3. org/TR/200 1/NOTE-wsdl-200 1 03 1 5#A3) . 

Les elements d'extensibilite utilises pour decrire ces liaisons sont specifiques a chaque technologie 
liee. lis sont rattaches a un espace de noms distinct de celui du document. Un element d'extensibilite 
n'est par defaut pas obligatoire dans le cadre d'une communication. Dans le cas contraire, cela doit 
etre precise via le booleen wsdl : requi red. 

Par exemple, le fragment d'element de liaison suivant exprime le fait que la presence d'un en-tete 
SOAP specifique est obligatoire dans le cadre particulier de la communication de ce message (Cal 1 - 
backHeader) : 

<input> 

<soap:header 

wsdl : requi red="true" 
message="tns: Call backHeader" 
part="Call backHeader" 
use="l iteral "/> 
<soap:body use="l iteral "/> 
</input> 

Les elements d'extensibilite propres a la mise en ceuvre de la liaison avec le protocole de transport 
SOAP vont etre decrits dans les sections qui suivent. 

La liaison avec le protocole SOAP 

Ann d'illustrer le fonctionnement concret de la liaison avec le protocole SOAP, nous allons mettre en 
ceuvre le modele du service de Google et presenter le resultat de l'interaction avec le port http://api 
.google.com/search/beta2. L'exemple ci-apres represente le resultat de l'utilisation de ce service au 
niveau du protocole HTTP. L'interaction a consiste a emettre une requete doGoogleSearch avec la 
chaine de caracteres Web Services passee en parametre. Le nombre maximal d' elements du resultat 
renvoye a ete volontairement reduit a 1 . La requete est emise a partir du programme client Java de test 
fourni dans le kit de Google. 

Voici le texte (formate) du message SOAP de requete emis vers le serveur de Google : 

POST /search/beta2 HTTP/1.0 

Host: api.google.com 

Content-Type: text/xml ; charset=utf-8 

Content-Length: 868 

SOAPAction: "urn:GoogleSearchAction" 

<?xml version='1.0' encoding='UTF-8' ?> 
<SOAP-ENV:Envelope 

xmlns: SOAP- E N V = " http://schemas.xml soap.org/soap/envel ope/" 

xmlns:xsi="http: //www. w3.org/1999/XMLSchema-instance" 

xmlns :xsd=" http://www.w3.org/1999/XMLSchema"> 

<SOAP-ENV:Body> 
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<nsl: doGoogl eSearch 

xml ns:nsl=" urn: Googl eSearch" 

SOAP- EN V:encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 
<key xsi :type="xsd:string">mykey</key> 
<q xsi :type="xsd:string">Web Services</q> 
<start xsi :type="xsd:int">0</start> 
<maxResul ts xsi :type="xsd:int">K/maxResul ts> 
<fil ter xsi :type="xsd:boolean">true</filter> 
<restrict xsi :type="xsd:string"X/restrict> 
<safeSearch xsi :type="xsd:boolean">false</safeSearch> 
<lr xsi :type="xsd:string"X/l r> 
<ie xsi :type="xsd:string">latinl</ie> 
<oe xsi :type="xsd:string">latinl</oe> 
</nsl:doGoogleSearch> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Et voici le texte (formate) du message SOAP de reponse renvoye par le serveur de Google a la 
requete precedente : 

HTTP/1.1 200 OK 

Date: Tue, 21 May 2002 09:37:05 GMT 

Server: e h c a p a 

Content-Length: 3806 

Connection: close 

Content-Type: text/xml ; charset=utf-8 

<?xml version^' 1.0' encoding='UTF-8'?> 
<S0AP-ENV:Envelope 

xml ns : SOAP -ENV=" http://schemas.xml soap. org/ soap/envelope/" 

xmlns:xsi=" http://www.w3.org/1999/XMLSchema -instance" 

xml ns:xsd=" http://www.w3.org/1999/XMLSchema"> 

<SOAP-ENV:Body> 

Voici maintenant le message de reponse doGoogl eSearchResponse au message de requete doGoogl eSearch. 
Cette reponse comprend un type de donnees complexe Googl eSearchResul t. 

<nsl: doGoogl eSearchResponse 

xml ns:nsl=" urn: Googl eSearch" 

SOAP- ENV:encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 

<return xsi :type="nsl: Googl eSearchResul t"> 

<documentFil tering xsi :type="xsd:boolean">fal se</documentFiltering> 
<estimatedTotal ResultsCount xsi :type="xsd:int">5480000</estimatedTotal Resul tsCount> 
<di rectoryCategories 

xml ns:ns2=" http://schemas.xml soap.org/soap/encoding/" 

xsi :type="ns2: Array" ns2:arrayType="nsl:Di rectoryCategory[l]"> 

<item xsi :type="nsl:Di rectoryCategory"> 

<special Encoding xsi :type="xsd:string"X/special Encoding> 

<full ViewableNamexsi :type="xsd:string">Top/Computers/Programming 

/Internet/Web_Services 
</ful lViewableName> 
</item> 
</directoryCategories> 
<searchTime xsi :type="xsd:double">0.061899</searchTime> 
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Voici le tableau d' elements du resultat de la recherche. Ce tableau est bien limite a un element (du 
type de donnees complexe ResultElement) comme demande dans les criteres de la recherche sur le 
moteur de Google. 

I<resultElements 
xmlns:ns3=" http://schemas.xml soap.org/soap/encoding/" 
xsi :type="ns3: Array" ns3:arrayType="nsl: Resul tEl ement [1]"> 

Premier element du tableau (item de coordonnee du tableau Resul tEl ement) : 

<item xsi : type=" nsl: Resul tEl ement "> 

<cachedSize xsi :type="xsd:string">14k</cachedSize> 
<hostName xsi :type="xsd:string"X/hostName> 
<snippet xsi :type="xsd:string"> 
<b>...</b> 
<b>Web</b> 
< b> Services< /b> Activity. 
<b>...</b> 

Working Drafts In Progress. Drafts produced by the 
&1 t ; b&gt : Web&l t ; /b&gt ; 
&1 1 ; b> Services< /b&gt ;<br> 
Architecture Working Group. 

8.1 1 ; b> Web&l t; /b> &1 1; b> Services< /b> 
Architecture Requirements. 
<b>...</b> 
</snippet> 
<directoryCategory xsi :type="nsl:DirectoryCategory"> 

<special Encoding xsi :type="xsd:string"></ special Encoding> 
<ful IViewableName xsi :type="xsd:string"X/ful 1 ViewableName> 
</di rectoryCategory> 

< related Information Present xsi :type="xsd:boolean">true 
</rel atedInformationPresent> 

<directoryTitle xsi :type="xsd:string"X/directoryTitle> 
<summary xsi :type="xsd:string"X/summary> 
<URL xsi:type="xsd:string">http://www.w3.org/2002/ws/</URL> 
<title xsi :type="xsd:string" 

>&1 t ; b> Web&l t; /b> &1 t; b> Services< /b&gt ;</title> 
</item> 
</resultElements> 

<end Index xsi :type="xsd:int">2</endlndex> 
<searchTips xsi :type="xsd:string"X/searchTips> 
<searchComments xsi :type="xsd:string"X/searchComments> 
<st art Index xsi :type="xsd:int">l</startlndex> 
<esti mate Is Exact xsi :type="xsd:boolean">false</estimateIsExact> 
<searchQuery xsi :type="xsd:string">Web Services</searchQuery> 
</return> 
</nsl:doGoogleSearchResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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Cet exemple montre la representation, sous la forme d' instances des messages SOAP de requete et 
reponse, emboites dans une requete/reponse HTTP, d'une interaction telle qu'elle est exprimee dans 
le modele WSDL initial de Google. 

Si nous reprenons les elements liaison et service de notre modele WSDL Google, voici comment 
sont introduits (en caracteres gras) les elements d'extensibilite qui permettent d'utiliser le protocole 
de transport SOAP (associes au prefixe soap) et de parvenir au resultat que nous venons d'obtenir. 

Definition de F unique liaison vers un protocole de transport, SOAP dans le cas present : 

<!-- Binding for Google Web APIs - RPC, SOAP over HTTP --> 
<binding name="GoogleSearch Binding" type="typens:GoogleSearchPort"> 
<soap:binding style="rpc" 

transport="http://schemas .xml soap. org/ soap/ http"/> 
<operation name="doGetCachedPage"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
</output> 
</operation> 

<operation name="doSpell ingSuggestion"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
</output> 
</operation> 

<operation name="doGoogleSearch"> 
<soap: operation soapAction="urn:GoogleSearchAction"/> 
<input> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
</input> 
<output> 
<soap:body use="encoded" 

names pace=" urn :GoogleSearch" 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/"/> 
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I</output> 
</operation> 
</binding> 

Definition du service et de son point d'acces correspondant : 

<!-- Endpoint for Google Web APIs --> 
<service name="GoogleSearchService"> 
<port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> 

<soap: address location="http://api .google. com/ search/beta 2 "/> 
</port> 
</service> 



Recommandations WS-I Basic Profile 1.0 (draft) 

Recommandation R2700 : une description WSDL ne doit utiliser que le protocole SOAP 1.1 lorsqu'une liaison 
SOAP est mise en oeuvre. Notamment, I'usage du protocole SOAP 1 .2 n'est pas admis. 



L' utilisation de ces differents elements d'extensibilite SOAP est decrite dans les sections qui suivent. 

L'element d'extensibilite SOAP binding 

L' element bindi rig est obligatoire lorsque Ton utilise une liaison SOAP dans le document WSDL (a ne 
pas confondre avec l'element WSDL binding). Celui-ci se presente ainsi dans la structure du document : 

definitions .... > 

<bi ndi ng .... > 

<soap:binding transport=°ur7° style="rpc|document"> 

</binding> 
</definitions> 

C'est cet element qui a pour fonction de preciser que la liaison du document WSDL est associee au 
format du protocole SOAP, et plus particulierement a Fun des elements Header, Body ou Envelope de 
la grammaire SOAP. Dans notre exemple Google, seules des associations de type body sont decrites. 

Lattribut sty! e s'applique par defaut a l'ensemble des operations incluses dans la liaison. Si celui-ci 
n'est pas precise, il prend la valeur document par defaut. Dans notre exemple, l'ensemble des opera- 
tions decrites adoptent le style rpc. Cette codification signifie que les operations de cette liaison sont, 
suivant le cas, orientees RPC (Remote Procedure Call), c'est-a-dire que les messages associes traitent 
des parametres et des valeurs de retour (et sont done conformes au format RPC de SOAP 1.1: voir 
http://www.w3.Org/TR/SOAP/#_Toc478383532), ou orientees document, c'est-a-dire que ces messages traitent 
des documents (et sont done conformes au format standard de SOAP 1.1). 

Lattribut transport est obligatoire et la valeur de l'URI precise le protocole de transport reel utilise 
par SOAP pour la communication. L'URI http://schemas.xmlsoap.org/soap/http designe la liaison au 
protocole HTTP dans la specification WSDL. Cependant, cet attribut pourrait preciser une liaison a 
d'autres protocoles, comme FTP (File Transfer Protocol) ou SMTP (Simple Mail Transfer Protocol) 
par exemple. 

Le service Web Google est done defini comme etant accessible en style RPC via un protocole SOAP 
sur HTTP. 
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RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2701 : une description WSDL qui presente un element de liaison SOAP binding doit impera- 
tivement utiliser I'attribut transport (elimination d'une divergence entre le texte de la specification WSDL et son 
schema XML). 

Recommandation R2702 : dans le cadre d'une liaison SOAP, une description WSDL doit imperativement utiliser le 
protocole HTTP(S) : la valeur de I'attribut transport d'un element de liaison SOAP binding doit etre affectee a la 
valeur http://schemas.xmlsoap.org/soap/http exclusivement. HTTP(S) est done le seul protocole de transport 
accepte dans le cadre de ce profil. 

Recommandation R2706 : dans le cadre d'une liaison SOAP, une description WSDL doit specifier la valeur 1 i teral 
pour I'attribut use. Cet attribut, optionnel selon le schema de liaison SOAP, et non decrit ci-avant (voir schema XML 
de la specification), devient done obligatoire et en outre se limite a I'usage de la representation litterale. 
Recommandation R2707 : cependant, si dans le cadre d'une liaison SOAP, une description WSDL ne specifie pas 
la valeur de I'attribut use, la valeur de cet attribut sera fixee par defaut a la valeur 1 i teral . Ceci ecarte de fait 
I'utilisation de differents encodages dont I'encodage SOAP (voir notamment sur ce sujet la polemique introduite sur 
la problematique des encodages, evoquee dans la remarque « Mise a I'ecart de I'encodage SOAP » section 5 du 
chapitre 1 7 de cet ouvrage). 

Recommandation R2708 : une description WSDL doit comporter au moins une liaison SOAP, compatible avec les 
recommandations du profil de base WS-I, par type de port (la raison d'etre de cette regie n'est pas explicitee). 
Recommandation R2709 : une description WSDL peut comporter plus d'une liaison SOAP, compatible avec les 
recommandations du profil de base WS-I, par type de port. 



L'element d'extensibilite SOAP operation 

Cet element se place de la maniere suivante dans la hierarchie du document WSDL (a ne pas confondre 
avec l'element WSDL operation) : 

definitions .... > 
<binding .... > 

<operation .... > 

<soap:operation soapAction="ur7" style="rpc|document"> 
</operation> 
</binding> 
</definitions> 

Lattribut style prend les memes valeurs que celui de l'element binding vu precedemment. Si cette 
valeur n'est pas specifiee, I'attribut prend par defaut la valeur de I'attribut sty! e defini au niveau de 
l'element binding. 

Lattribut soapActi on specifie la valeur de l'en-tete HTTP SOAPActi on. Cet URI est obligatoire en cas 
de description d'une liaison du protocole SOAP sur HTTP. En revanche, pour les liaisons SOAP sur 
d'autres protocoles, il ne doit pas etre precise, et dans ce cas, l'element operation peut (may) etre 
omis. 

Dans l'instance de requete HTTP de l'exemple Google, I'attribut soapActi on a recu la valeur 
urn:GoogleSearchAction pour l'operation doGoogleSearch, valeur que Ton retrouve dans l'en-tete 
HTTP correspondant du message SOAP. 
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Difficultes d'interoperabilite 

Les valeurs prises par les deux attributs sty 1 e et soapActi on sont importantes et sont souvent a I'origine de diffi- 
cultes en termes d'interoperabilite entre systemes heterogenes (voir a ce sujet la remarque « SOAP ' rpc/enco- 
ded ' vs SOAP ' document/literal ' » consacree a I'utilisation de I'attribut styl e dans le chapitre 17 : « Le defi de 
I'interoperabilite »). 

En effet, d'une maniere generale, les implementations Java fonctionnent par defaut en mode rpc, a I'inverse de 
Microsoft qui s'appuie sur un fonctionnement par defaut en mode document. Ceci oblige dans certaines situations 
a faire des ajustements pour autoriser la communication entre ces environnements. 

De meme, la codification de la valeur donnee a I'attribut soapActi on est laissee libre, ce qui, la encore, laisse le 
champ libre a des interpretations de la part des auteurs d'implementations SOAP et entraine done des difficultes. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2705 : dans le cadre d'une liaison SOAP, toutes les operations d'un meme type de port doivent 
posseder un attribut styl e dont la valeur est identique : soit rpc, soit document. Le melange est interdit. 
Recommandation R271 : le profil de base decrit la signature d'une instance (wire signature) d'operation a I'interieur 
d'un type de port via le nom qualifie de I'element fils du corps du message SOAP (nsl:doGoogleSearch dans 
I'exemple Google). Si celui-ci est vide, ce nom correspond a une chaine vide. Toutes les operations d'un type de 
port donne d'une description WSDL doivent imperativement correspondre a des signatures d'instances uniques. 
Ceci permet de lever une ambigu'fte, evoquee precedemment, relative au fait que I'unicite du nom des operations 
n'est pas requise par la specification WSDL.. 

Recommandation R2713 : dans le cas ou la valeur de I'attribut soapAction de I'element operation est vide 
(e'est-a-dire est egale a ""), cette description WSDL doit etre trait.ee comme equivalents a une description dans 
laquelle I'attribut soapActi on est omis (voir problemes d'interoperabilite exposes dans la section « SOAP Builders 
Round I » du chapitre 17). Cette recommandation concerne le comportement d'un processeur WSDL et permet 
ainsi de contourner la difference semantique entre ces deux valeurs du point de vue de la specification SOAP 1.1. 
Recommandation R2714 : dans le cadre d'une interaction a sens unique (one-way), les instances de services Web 
ne doivent pas renvoyer de reponses HTTP qui contiennent un message SOAP (pas d'enveloppes retournees). 
Recommandation R271 5 : dans le cadre d'une interaction a sens unique (one-way), les instances de services Web 
ne doivent pas considerer que la communication est terminee tant qu'un code retour HTTP 202 (Accepted) n'a pas 
ete regu par le client HTTP. De meme, la reception de ce code retour ne doit pas etre interpretee par I'emetteur 
comme une reconnaissance de la validite du message ou comme une certitude que le recepteur le traitera. 
Recommandation R2716: I'attribut namespace ne doit pas etre specifies dans les elements operation d'une 
liaison SOAP lorsque I'attribut styl e est fixe a la valeur document et I'attribut use est fixe a la valeur 1 i teral . 
Ceci est valable pourtous les sous-elements concernes d'un element operation, e'est-a-dire pour les elements 
d'extensibilite SOAP body, header, headerf aul t et f aul t (voir la description de ces elements ci-apres). 

Recommandation R2717 : I'attribut namespace doit etre imperativement specifie comme un URI absolu dans les 
elements operation d'une liaison SOAP lorsque I'attribut style est fixe a la valeur rpc etque I'attribut use est 
fixe a la valeur literal . Cela est valable pour tous les sous-elements concernes d'un element opera ti on, e'est- 
a-dire pour les elements d'extensibilite SOAP body, header, headerf aul t et fault (voir la description de ces 
elements ci-apres). 

Recommandation R2718 : dans une description WSDL, la liste des operations d'un type de port doit correspondre 
a celle du type de port equivalent dans une description de liaison SOAP. 
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L'element d'extensibilite SOAP body 

L'objectif de l'element d'extensibilite body est de decrire la structuration du corps du message SOAP 
(soapenv : Body). Cet element d'extensibilite s'utilise pour des messages de style rpc ou document (voir 
attribut style de l'element englobant operation). Selon le type de l'operation, la structure du corps 
SOAP sera differente : 

• Si le style est de type document, les parties du message sont integrees directement dans le coips du 
message SOAP. 

• Si le style est de type rpc, la specification SOAP (voir section 7. 1 « RPC and SOAP Body » : http://www 
.w3.org/TR/SOAP/#_Toc478383533) precise que chacune des parties du message (parametres et valeur 
de retour) est englobee dans une structure (wrapper) et ordonnee selon l'ordre de la signature de la 
methode correspondante. L'element englobant (wrapper) possede un nom identique a celui de 
l'operation concernee et se trouve rattache a l'espace de noms precise par l'attribut namespace (par 
convention, la chaine de caracteres Response est concatenee au nom du wrapper pour les messages 
de reponse). Chacune des parties possede un accesseur dont le nom est identique a celui du para- 
metre correspondant de la methode (pour les messages de reponse, le premier accesseur est celui 
de la valeur de retour). 

Si nous reprenons l'exemple de la reponse HTTP du serveur de Google, l'invocation de l'operation 
doGoogleSearch, qui utilise le style rpc, induit la generation d'un element wrapper doGoogleSearch- 
Response dans le corps du message de reponse SOAP. Sous cet element, l'element return a ete genere 
et permet ainsi d'acceder au contenu de la reponse (voir partie du meme nom dans le message 
doGoogl eSearchResponse du modele WSDL du service Google). 

L'element body se presente ainsi dans le document WSDL : 

definitions .... > 
<binding .... > 

<operation .... > 
<input> 

<soap:body parts="wnto/cens" use="literal | encoded" 

encodingStyle="ur7- list" namespace="u/"7'"> 
</input> 
<output> 

<soap:body parts="™to/cens" use="literal |encoded" 

encodingStyle="t/r7- list" namespace="ur7'"> 
</output> 
</operation> 
</bi ndi ng> 
</definitions> 

L'attribut parts est optionnel. S'il n'est pas specifie, toutes les parties du message sont incluses dans 
le corps du message SOAP. Lorsqu'il est specifie, il precise quelles parties du message doivent 
apparaitre dans le corps du message SOAP. 

Les parties d'un message peuvent etre soit des descriptions de schemas concrets, soit des definitions 
de types abstraits. S'il s'agit de types abstraits, ceux-ci sont « concretises » via une serialisation 
realisee selon les regies associees au style d'encodage specifie. 
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L'attribut use donne une indication d' utilisation d'un encodage particulier des parties du message ou, 
au contraire, stipule que celles-ci constituent le schema concret du message. Si la valeur encoded est 
specifiee, cela signifie que chaque partie du message reference un type abstrait. Dans ce cas, la valeur 
de l'attribut encodi ngStyl e precise le style de codage a appliquer a ces types abstraits arm de produire 
un message concret. 

L'attribut encodi ngStyl e contient une liste d'URI separes par une espace. Chaque URI correspond a un 
encodage utilise dans le message. Les URI sont classes de l'encodage le plus restrictif au moins restric- 
tif, comme pour le parametre homonyme de la specification SOAP (voir la section dediee aux styles de 
codage dans les messages SOAP du chapitre 8 « Echanger avec un service - Codage des donnees »). 

Les trois operations de notre exemple Google presentent le meme profil pour tous les messages de 
requete et de reponse : le message complet est inclus dans le corps SOAP (attribut parts absent) et il 
est encode (attribut use="encoded") selon le seul style d' encodage SOAP 1.1 (attribut encodingStyle 
=" http://schemas.xml soap.org/soap/encoding/"). 

L'element d'extensibilite SOAP fault 

L'element fault permet d'exprimer comment sera code l'element detail, enfant de l'element 
soapenv: Fault du message d'erreur SOAP. 

L'element f aul t se place de la maniere suivante dans l'arbre du document WSDL : 

definitions .... > 
<bi ndi ng .... > 
<operation .... > 
<fault> 

<soap:fault name="™to/cen" use="literal |encoded" 
encodi ngStyl e="uri- 1 ist" namespace="ur7'"> 
</fault> 
</operation> 
</binding> 
</definitions> 

L'attribut name de l'element soap : f aul t permet de faire le lien avec l'element WSDL f aul t associe a 
1' operation. 

Un message fault nepeut avoir qu 'une seule partie (restriction sur l'attribut parts dutype soap: body). 
Les autres attributs (use, encodingStyle et namespace) fonctionnent de la meme maniere que ceux de 
l'element soap: body. 

L'exemple Google ne prevoit pas l'usage d'elements d'extensibilite SOAP f aul t. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2721 : dans une description WSDL, les elements fault d'une description de liaison SOAP 
doivent specifier la valeur de l'attribut name (incoherence entre le texte de la specification WSDL et son schema XML). 
Recommandation R2722 : dans une description WSDL, si un element fault d'une description de liaison SOAP 
specifie la valeur de l'attribut use, celle-ci doit imperativement etre egale a 1 1 teral . 

Recommandation R2723 : dans une description WSDL, la specification de la valeur de l'attribut use dans un 
element f aul t d'une description de liaison SOAP est optionnelle. Si elle n'a pas ete specifiee, elle doit etre consi- 
dered comme etant egale a literal. 
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Les elements d'extensibilite SOAP header et headerfault 

Les elements header et headerfault permettent de decrire Fen-tete du message SOAP (voir partie 
dediee a la gestion des erreurs de SOAP 1.1 dans le chapitre 7 « Echanger avec un service - Format 
du message »). 

Des en-tetes, pour des besoins d'extension de WSDL, peuvent etre documentes (par defaut, attribut 
wsdl :required="false") ou rendus obligatoires (attribut wsdl :required="true") dans le cadre d'une 
communication particuliere (voir exemple precedent dans la section « Les liaisons standards »). Ces 
en-tetes peuvent etre directement ajoutes au message SOAP, sans etre decrits a ce niveau. 

Ces elements sont positionnes ainsi dans la hierarchie du document WSDL : 

definitions .... > 
<binding .... > 
<operation .... > 
<input> 

<soap:header message="gname" part=" nmtoken" use="literal |encoded" 
encodings tyle= n ur7- list" namespace="ur7'"> 

<soap:headerfault message="(77iame" part="w7ito/<e/7"use="literal |encoded" 
encodingStyle="t/r7- 7 7s£"namespace=" ur 7 "/> 
</soap:header> 
</input> 
<output> 

<soap:header message="q™me" part=" nmtoken" use="literal |encoded" 
encodingStyle="t/r7-7 7'st" namespace="(vr7'"> 

<soap:headerfault message="c7/7a/7je" part="™to/<e77"use="literal |encoded" 
encodingStyle="t/r7'-7 7'st"naniespace="ur7 , "/> 
</soap:header> 
</output> 
</operation> 
</binding> 
</definitions> 

Les attributs message et part permettent de referencer la partie de message qui se situe dans Fen-tete 
SOAP. Le schema reference par cette partie de message peut comporter une definition des attributs 
soap: actor et soap: must Understand lorsque la valeur de F attribut use estfixee a la constante literal. 
En revanche, ces definitions ne peuvent etre presentes si la valeur de cet attribut est fixee a la constante 
encoded. II n'est pas necessaire que le message reference soit identique au message qui definit le 
corps SOAP. Plusieurs elements header peuvent etre definis a Finterieur d'un element i nput ou output. 

Les sous-elements headerfault presentent la meme structure que leurs elements parents header. 
Plusieurs elements headerf aul t (optionnels) peuvent etre definis a Finterieur d'un element header. Les 
elements headerfault ont pour objectif de preciser les elements header susceptibles de renvoyer des 
informations au travers du protocole SOAP relatives a des erreurs liees a Felement header qui englobe 
Felement headerfault. 

Quant aux attributs use, encodingStyle et namespace, ils fonctionnent de la meme maniere que ceux 
de Felement body vu precedemment. 
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L'exemple Google ne prevoit pas l'usage d'elements d' extensibility SOAP header et headerfault. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2719 : dans une description WSDL, la specification d'elements headerfault dans la description 
des elements input et output d'une operation est optionnelle (incoherence entre le texte de la specification 
WSDL et son schema XML). 

Recommandation R2720 : dans une description WSDL, la specification d'elements header et headerf aul t dans 
la description des elements i nput et output d'une operation doit etre effectuee en affectant une valeur de type 
NMTOKEN a I'attribut part (incoherence entre le texte de la specification WSDL et son schema XML : le schema 
XML declare unattribut parts detype NMTOKENS). 



L'element d'extensibilite SOAP address 

L'element est positionne ainsi dans la hierarchie du document WSDL : 

definitions .... > 
<binding .... > 

I <soap: address location="i/r7'"/> 

</binding> 
</definitions> 

Cet element permet d'affecter une adresse a un port WSDL. Le schema de FURI doit bien sur etre en 
relation avec le protocole de transport specifie via l'element soap: binding. 

Dans le service Google, I'attribut transport precise que ce service est fourni par F intermediate du 
protocole HTTP (http://schemas.xmlsoap.org/soap/http). LURI d'acces au service declinee dans 
I'attribut location (voir http://api.google.com/search/beta2) respecte done le schema HTTP. 

Un port qui s'appuie sur une liaison SOAP doit obligatoirement fournir une et une seule adresse. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R2711 : une description WSDL peut comporter plusieurs ports dont les attributs location de 
l'element address pointent vers le meme URI. 



La liaison avec le protocole HTTP GET/POST 

L'utilisation d'une liaison au protocole HTTP GET/POST fait l'objet d'une description par la speci- 
fication WSDL. 

La bonne comprehension des chapitres suivants ne necessite pas d'explications detaillees sur cette 
partie de la specification. Les exemples decrits plus avant dans ce livre exploitent essentiellement la 
liaison avec le protocole SOAP. Le lecteur pourra se reporter a la section 4 « HTTP GET & POST 
Binding » (voir http://www.w3c.Org/TR/2001/NOTE-wsdl-20010315#_http) du document pour etudier cette 
liaison de maniere detaillee. 

La liaison avec le format de message MIME 

La specification WSDL prevoit l'utilisation du format de message MIME. II est en effet possible de 
lier des types abstraits a des messages concrets de ce type. 
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Plus particulierement, la specification definit les liaisons pour les types MIME suivants : 

• le type multipart/related ; 

• le type text/xml ; 

• le type appl ication/x-www-form-url encoded ; 

• les autres types. 

La liste n'est pas exhaustive et les autres types sont geres en specifiant la chaine de caracteres qui 
identifie le type MIME. 

Cette partie de la specification n'est pas necessaire a la comprehension des chapitres suivants et nous 
renvoyons le lecteur a la specification WSDL (section 5 « Mime Binding » : voir http://www.w3c.org/TR/ 
2001/NOTE-wsdl-20010315#_Toc492291084) pour une information complete sur ce type de liaison. 

WSDL dans le « monde reel » 

Nous venons de passer en revue la specification WSDL qui permet done de decrire simplement un 
service Web et la maniere dont il est possible d'y acceder. Cet element de la trilogie SOAP, WSDL et 
UDDI est extremement important car il apporte la brique de base necessaire a la definition et a la 
reutilisation des services Web. C'est la presence de WSDL qui permet de qualifier cet ensemble de 
specifications de technologies de services Web. 

En effet, de nombreuses implementations de services Web se sont limitees a F utilisation de la couche 
de transport SOAP entre les nceuds de communication qui prennent en charge la communication. 
Cela est suffisant dans une situation oil le service en question ne presente qu'un interet limite, propre 
aux deux acteurs qui controlent les nceuds de communication concernes. En revanche, si le service 
Web est destine a une utilisation dans un cadre plus elargi, il va rapidement devenir fastidieux pour le 
fournisseur de ce service de decrire et d' informer chaque consommateur potentiel des caracteristiques 
fonctionnelles et techniques de ce service. II sera certainement preferable que ce fournisseur concentre 
ses ressources sur les aspects commerciaux et contractuels de son offre par exemple. 

Ainsi, la specification WSDL joue un role pivot dans une architecture de services Web. C'est la 
presence d'un contrat WSDL qui permet d'affirmer que Ton met en ceuvre un service Web. Le seul 
usage de SOAP dans la communication entre applications reparties ne suffit pas pour qualifier ces 
applications de services Web. De meme, il faut rappeler que le protocole SOAP n'est pas le seul 
protocole utilisable dans une telle architecture : l'extensibilite WSDL permet de s'appuyer sur des 
liaisons a d'autres protocoles de transport et a d'autres formats de message et eventuellement de les 
faire cohabiter via le mecanisme des ports alternatifs. 

La couche de description de service WSDL permet done de publier les caracteristiques fonctionnelles 
et techniques d'un service Web, elements importants d'un contrat de service. En effet, pour pouvoir 
utiliser ou reutiliser un service Web, il faut deja commencer par faire savoir qu'il existe et done le 
publier. Cette publication peut etre realisee a grande echelle, a destination du public le plus large 
(concepteurs, developpeurs, etc.), ou bien dans le cadre d'une communaute d'interets communs plus 
reduite, comme un extranet ou un groupe multisociete par exemple, et enfin dans le cadre tres limite 
d'une entreprise. C'est cette fonction d'information qui est devolue a la couche WSDL de la trilogie. 



Technologies des services Web 

Deuxieme Partie 

Le dernier niveau de la trilogie actuelle est charge de prendre en compte les canaux de diffusion de 
ces services. Ce role est couvert par les annuaires UDDI, et fait l'objet des deux chapitres suivants. 
Ces annuaires, prives ou publics, ont pour objectif de faciliter la recherche de services publies offerts 
via une grande variete de canaux d'acces et dont les documents au format WSDL ne represented 
qu'un seul des canaux possibles (au sens UDDI). Ces annuaires offrent la particularite d'etre accessibles 
par F intermediate d'Internet de deux manieres differentes : 

• soit par un etre humain, a partir d'une interface Web classique ; 

• soit de maniere automatique, par un processus programme. 

Une analogie certaine peut etre effectuee avec les annuaires DNS (Domain Name Service). En effet, de 
meme que les annuaires DNS permettent de retrouver Fadresse IP d'un ordinateur (protocole TCP/IP : 
Transmission Control Protocol/Internet Protocol) a partir de son nom de domaine, les annuaires UDDI 
offrent la capacite de retrouver le point d'acces a un service donne a partir du nom du service offert 
ou du nom de l'entreprise qui offre ce service. 

Nous venons de voir comment est imbriquee la specification WSDL et le role central qu'elle joue 
dans la trilogie SOAP, WSDL et UDDI. Ce role a conduit les concepteurs et developpeurs de services 
Web a manipuler en permanence des descriptions de services Web en format WSDL. De fait, les editeurs 
de logiciels et d'environnements de developpement ou de conception ont rapidement structure leurs 
offres autour de la gestion de ces documents WSDL. 

Les differents aspects, lies a l'utilisation de WSDL, sont illustres chapitre 13, lequel traite des principes 
de mise en ceuvre des services Web, des problemes de plates-formes de developpement, de deploiement 
et d'execution et enfin du role pivot joue par les documents WSDL dans ce type d' architecture. 

Outils et ressources 

Outre F offre en matiere d'environnements de developpement aptes a produire des services Web et les 
descriptions WSDL associees, d'autres outils, en nombre toujours plus important, sont apparus afin 
de rendre la vie plus facile aux developpeurs et aux concepteurs. La nature de ces outils est de plus en 
plus diversifiee. 

A l'instar des outils de test generes automatiquement a partir du code source d'un service en cours 
d'ecriture, dans les grands environnements de developpement tels que Visual Studio .NET de Microsoft 
ou WebSphere Studio Application Developer dTBM, apparaissent de plus en plus d' outils equivalents, 
capables de fonctionner de maniere autonome. 

Outil WSDL Dynamic Test Client de IONA Technologies 

Parmi ceux-ci, nous pouvons citer 1' outil WSDL Dynamic Test Client, present dans le serveur 
d'integration et de deploiement de services Web de IONA Technologies, Orbix E2A XMLBus 
Edition 5.0.3. L'ecran figure 10-2 presente la page d'accueil de cet outil. 

Dans cet exemple, nous avons fait pointer le champ de saisie de Fadresse du fichier WSDL a traiter 
vers l'URL du fichier Echo.wsdl genere dans les exemples du chapitre 13 via l'assistant du SOAP 
Toolkit de Microsoft. La demande de traitement du document WSDL provoque son telechargement et 
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le declenchement de son analyse syntaxique par l'outil. Cette analyse permet ensuite de generer 
dynamiquement la liste des operations fournies par le service. 
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Figure 10-2 

Presentation des operations du service Web Echo par V assistant de Orbix E2A. 



d^: Intranet local 



L'utilisateur peut alors selectionner Tune des operations possibles et demander la generation automa- 
tique d'un formulaire de test. Ce formulaire de test presente la liste des parametres de F operation 
choisie qui peuvent etre saisis ou non selon la nature de l'operation. Ensuite, l'utilisateur peut activer 
1' invocation de l'operation a destination du serveur qui heberge 1' implementation du service 
presente. 
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Figure 10-3 

Invocation dynamique d'une operation du service Web Echo par Vassistant de Orbix E2A. 



L'ecran figure 10-4 presente le resultat de Finvocation dynamique de 1' operation EchoString. Cet 
ecran affiche le resultat renvoye par F activation du service, ici la chaine de caracteres Test saisie par 
l'utilisateur et renvoyee en echo par le serveur COM, resultat accompagne du message SOAP de 
requete emis par le serveur Orbix E2A, ainsi que du message SOAP de reponse renvoye par le 
serveur Microsoft IIS 5.0. 
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Figure 10-4 

Resultat de I 'invocation dynamique de I 'operation EchoString par I 'assistant d'Orbix E2A. 

II faut noter que cet outil est encore tres recent et ne prend en charge que les types de donnees 
simples. Par exemple, si Ton cherche a invoquer F operation EchoXML, l'assistant ne sera pas en 
mesure de le faire. En effet, il ne prend pas encore en charge les donnees de type binaire base 64, les 
types complexes et les tableaux. 
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Nous pouvons egalement remarquer qu'a travers cet exemple, nous venons de mettre en oeuvre, de 
maniere tres simple, une interaction entre un serveur Microsoft IIS 5.0 et un serveur d' applications 
Java, via les protocoles SOAP et HTTP. Le produit XMLBus de IONA Technologies se presente 
comme un container de services Web apte a fonctionner a l'interieur d'un moteur J2EE, quel qu'il 
soit, ou de maniere autonome. Les serveurs Java compatibles avec cette version sont Orbix E2A, le 
serveur d' applications de IONA, les serveurs WebLogic6.1 de BEA, WebSphere 4.0 dTBM et 
Tomcat 4.0.3 d' Apache (utilise dans la version autonome). L' implementation SOAP utilisee par 
IONA est celle d' Apache. 

Notons que ce meme outil est accessible en ligne dans la section du site de IONA dediee a l'inter- 
operabilite (voir http://interop.xmlbus.com:7002/WSDLCIient/index.html) et peut etre utilise pour tout document 
WSDL present sur Internet, obtenu de maniere directe ou via un annuaire UDDI public (pas de possibility 
& upload a partir d'un intranet pour Finstant). 

Service Web de verification WSDL GotDotNet 

Le site de la communaute GotDotNet, liee au framework .NET (http://www.gotdotnet.com) de Microsoft, 
propose un service Web de verification de documents WSDL et de generation d'un proxy-service C# 
correspondant si celui-ci est bien forme selon la specification WSDL 1.1. 

Le service accepte les parametres suivants : 

• input : 

- type Stri ng : URL du fichier WSDL ; 

• output : 

- type Stri ng : message d'information genere en cas de succes (balise <StandardOutput>) ; 

- type Stri ng : message d'information genere en cas d'erreur (balise <ErrorOutput>) ; 

- type Stri ng : le code source de la classe du proxy-service genere en cas de succes (balise <Code>) ; 

- type String : indication sur la cause de l'erreurgenereeencas d'erreur (balise <ErrorHints>). 

Ce service est accessible a http://www.gotdotnet.com/services/wsdl/wsdlverify.asmx?op=ValidateWSDL Si Ton 
s'en sert, par exemple pour generer le proxy-service C# capable de l'invoquer, il suffit de lui fournir 
en parametre FURL http://www.gotdotnet.com/services/wsdl/wsdlverify.asmx7WSDL qui correspond a sa propre 
description de service WSDL. 
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SOAP 

The following is a sample SOAP request and response. The placeholders shown need to be replaced with actual values. 

POST /services/ wsdl/wsdlverify . aairix HTTP/1. 1 

Hu 3L: i.i.i u.i w . i j u Ldu Lue L . cum 

Content-Type : text/ xml ; charset=utf -8 

Content- Length: lengtli 

SOAPAct ion : "http : / /microsoft . com/ net/ wsdlver if y/ValidateWSDL" 

<?xml version= rr 1.0" encoding="utf-8 rr ?> 

<soap: Envelope xmlns:xsi= ,r http : //www.w3 . org/200 1/XHLSchema-iDstance" xnilos: x3d="http://wBTiT. w3 . org/2 0Ol/XHLSc 
<soap : Body> 

<ValidateIiISDL xmlns="'http : / /microsoft . com/ net/ wsdlverif y ,r > 

<url>strin<j</url> 
</ValidateWSDL> 
</soap:Body> 
</soap : Envelope> 

lJ I 
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Figure 10-5 

Verification du service Web WsdlVerify de GotDotNet par lui-meme. 



Par cette action, on recupere done en retour un document XML qui contient le code source du proxy- 
service en langage C# correspondant a ce service. Le code source genere est le suivant : 

Importation des librairies .NET necessaires au fonctionnement du proxy-service : 

// <autogenerated> 



This code was generated by a tool. 
Runtime Version: 1.0.3705.209 



Changes to this file may cause incorrect behavior and will be lost if 

the code is regenerated. 

// </autogenerated> 
// 

// 
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II This source code was auto-generated by wsdl , Version=l .0.3705.209. 

// 

using System. Diagnostics; 

using System. Xml .Serial ization; 

using System; 

using System. Web. Services. Protocols; 

using System. ComponentModel ; 

using System. Web. Services; 

Classe Wsdl Verify utilisable via le protocole SOAP/HTTP : 



I 



/// <remarks/> 

[System.Diagnostics.OebuggerStepThroughAttribute( )] 

[System. ComponentModel .DesignerCategoryAttribute( "code")] 

[ Sy s tern. Web. Services. WebServiceBindingAttribute(Name=" Wsdl Verify Soap" , 

Namespace="http: //mi crosoft.com/net/wsdl verify")] 

public class WsdlVerify : System. Web. Services. Protocol s.SoapHttpCl ientProtocol 

/// <remarks/> 

publ ic WsdlVerify( ) { 

this.Url = "http://www.gotdotnet.com/services/wsdl /wsdl verify. asmx" ; 



/// <remarks/> 

Methode GetServiceHits( ) du service, invocable de maniere synchrone ou asynchrone : 

[ System. Web. Services. Protocol s.SoapDocumentMethodAttribute( 

"http://microsoft.com/net/wsdlverify/GetServiceHits" , 

Request Namespace=" http://microsoft.com/net/wsdl verify" , 

ResponseNamespace="http: //mi crosoft.com/net/wsdl verify" , 

Use=System.Web.Services.Description.SoapBindingUse. Literal , 

Pa rameterStyle=Sys tern. Web. Services. Protocol s.SoapParameterStyle. Wrapped)] 

public int GetServiceHits( ) { 

object[] results = this. InvokeC'GetServiceHits" , new object[0]); 
return (O'ntXresul ts[0]) ) ; 

} 

/// <remarks/> 

public System. IAsyncResult BeginGetServiceHits(System.AsyncCal Iback callback, 

object asyncState) { 

return this.BeginlnvokeC'GetServiceHits" , new object[0], call back, asyncState) ; 



/// <remarks/> 

public int EndGetServiceHitstSystem. IAsyncResult asyncResult) 

object[] results = this.Endlnvoke(asyncResult) ; 

return (O'ntXresul ts[0]) ) ; 
} 

/// <remarks/> 
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Methode Val idateWSDLt ) invoquee dans Finterface Web : 

[System. Web . Servi ces . Protocol s . SoapDocumentMethodAttri bute( 
"http://microsoft.com/net/wsdlverify/Val idateWSDL" , 
RequestNamespace="http: //mi crosoft.com/net/wsdl verify" , 
ResponseNamespace=" http://microsoft.com/net/wsdl verify" , 
Use=System. Web. Servi ces. Descripti on. SoapBindingllse. Literal , 
Pa rameterStyle=Sy stem. Web. Servi ces. Protocol s.SoapParameterStyle. Wrapped)] 
public WsdlResults ValidateWSDL(string url ) { 

object[] results = this . InvokeC'Val idateWSDL" , 

new object[] {url } ) ; 
return ( (Wsdl Results) (results [0]) ) ; 
} 

/// <remarks/> 

public System. IAsyncResult BeginVal idateWSDLtstring url. System. AsyncCallback cal 1 back, 

object asyncState) { 

return this .Begin InvokeC'Val idateWSDL" , 

new object[] {url), callback, asyncState); 
} 

/// <remarks/> 

public WsdlResults EndVal idateWSDL(System. IAsyncResult asyncResult) { 

object[] results = this . EndInvoke(asyncResul t) ; 

return ( (Wsdl Results) (results [0]) ) ; 



Classe Wsdl Resul ts de serialisation des resultats obtenus par le verificateur WSDL : 

/// <remarks/> 

[System. Xml .Serial ization.XmlTypeAttribute(Namespace=" http://microsoft.com/net/wsdl verify")] 

public class WsdlResults { 

/// <remarks/> 

public string StandardOutput; 

/// <remarks/> 

public string ErrorOutput; 

/// <remarks/> 
public string Code; 

/// <remarks/> 
public string ErrorHints; 
} 

Ce proxy-service, apres compilation, peut etre appele par d'autres programmes comme ce petit 
programme C# qui fonctionne en mode Console et qui verifie a nouveau le meme fichier WSDL. Les 
resultats peuvent etre affiches dans la fenetre Debug de Visual Studio .NET. 

I using System; 
using System. Diagnostics; 
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namespace WsdlVerify { 
class Client { 
[STAThread] 
static void Main(string[] args) { 

String url = "http://www.gotdotnet.com/services/wsdl 

/wsdl verify. asmx?WSDL" ; 
Debug. WriteLineC'about to verify : "+url ) ; 
WsdlVerify verifier = new Wsdl VerifyO ; 
WsdlResults results = verifier. Val idateWSDKurl ) ; 



Debug. WriteLine( "verifier standard output 

Debug. WriteLine( "verifier error output 

Debug. WriteLine("verifier code 

Debug. WriteLineC"verifier error hints 



"+results.StandardOutput) ; 
"+results.ErrorOutput) ; 
"+results.Code) ; 
"+results.ErrorHints) ; 



Conclusion : instrumentalisation de la gestion 
des documents WSDL 

Nous venons de voir deux outils parmi de nombreux autres, accessibles en ligne ou non, aux 
fonctionnalites plus ou moins riches. On s'apercoit, et la lecture du chapitre 13 « Principes de mise 
en ceuvre » est encore plus edifiante a ce sujet, que les documents WSDL sont et seront de moins en 
moins manipules directement par les developpeurs ou les concepteurs de services Web. Ceux-ci 
disparaissent de plus en plus derriere des outils de natures tres diversifiees et sont soit generes par 
d'autres documents, soit sources de generation d'autres documents. 

Ce role central de WSDL est parfaitement mis en valeur par le framework d' invocation de services 
Web WSIF (Web Services Invocation Framework) d'origine IBM, dont revolution est maintenant 
prise en charge par la communaute Apache. Ce paquetage Java, initialement developpe par IBM (voir 
ressource alpha Works : http://www.alphaworks.ibm.com/tech/wsif), a ete donne (voir annonce : http://www-91 6 
.ibm.com/press/pmews.nsf/print/F6AA1FA152C47FBF85256BE50058CDBA) le 27 juin 2002 a la communaute 
Apache, en meme temps que le paquetage WSIL4J (implementation Java de la specification WSIL ou Web 
Services Inspection Language). Depuis, la communaute Apache a fait evoluer cette implementation 
et une version 2.0 est maintenant telechargeable a partir du site d' Apache (voir http://ws.apache.org/wsif). 

Le framework WSIF est tres interessant dans la mesure ou il offre un moyen de faire abstraction des 
protocoles de transport utilises par les services Web, dont SOAP notamment. En effet, la plupart 
des exemples de mise en ceuvre de services Web que Ton peut trouver utilisent directement SOAP et 
presentent done les contingences qui lui sont propres. Et cela, meme si ces exemples font parfois appel 
a la description WSDL de ces services, tout au moins pour recuperer l'adresse d'acces a ces services. 

Nous avons vu de quelle maniere WSDL permet de specifier abstraitement les operations d'un service 
Web et les messages associes, puis comment ces descriptions peuvent etre associees a des protocoles 
de transport et a des formats de message concret. WSIF propose tout simplement d'exploiter cette 
caracteristique de WSDL et offre au developpeur un moyen tres interessant de manipuler les fonctions 
du service Web sans se preoccuper des protocoles de transport sous-jacents (SOAP, JMS, EJB...). 
WSIF permet egalement de faire de F invocation statique ou dynamique de services Web. II offre en 
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outre la possibilite de commuter les protocoles utilises ou les points d'acces a ces services sans 
aucune recompilation du client. 

Cependant, cette disparition annoncee des documents WSDL derriere les outils de conception et de 
developpement n'est que virtuelle et ne saurait faire oublier l'importance de leur role pivot dans 
l'ensemble des specifications en attente de normalisation qui constituent les fondements des services 
Web : la trilogie SOAP, WSDL et UDDI. Nous pouvons meme aisement prevoir qu'un effort impor- 
tant de reutilisation des standards metier XML, definis ces deux dernieres annees par de nombreuses 
organisations, sera mene : ces documents XML seront soit directement integres dans les documents 
WSDL qui les utiliseront sous forme de schemas, soit plus vraisemblablement references par des 
scenarios de conversations ou de processus metier qui les exploiteront dans le cadre des interactions 
entre les participants de ces echanges (a F image de ce que propose la specification WSCL de 
Hewlett-Packard, par exemple : voir chapitre 21 « Gestion des processus metier »). 

Sites de reference 

Les differentes references de cette specification sont localisees de la maniere suivante : 

• note de reference de la version 1.1 soumise le 15 mars 2001 au W3C : http://www.w3.org/TR/wsdl ; 

• document de reference de la version 1 . 1 publie le 23 Janvier 2001 et maintenu sur le site de Microsoft : 

http://msdn.microsoft.com/xml/general/wsdl.asp; 

• document de reference de la version 1 .0 publie le 25 septembre 2000 et maintenu sur le site d'IBM : 
http://www-1 06.ibm.com/developerworks/library/w-wsdi. htmi?dwzone=ws; 

• Web Services Description Working Group du W3C : http://www.w3.org/2002/ws/desc ; 

• document de reference de la version 1.2 (Working Draft) publie le 24 Janvier 2003 par le W3C : 
http://www.w3.org/TR/wsdl1 2. 

Outils 

• Apache WSIF (Web Services Invocation Framework) : http://ws.apache.org/wsif; 

• GotDotNet .NET Webservice Studio : http://www.gotdotnet.com/team/tools/web_svc ; 

• GotDotNet WSDL Browser : http://apps.gotdotnet.com/xmltools/WsdlBrowser; 

• GotDotNet WSDL Verification : http://www.gotdotnet.com/services/wsdl/wsdiverify.asmx ; 

• IONA Technologies WSDL Dynamic Test Client : http://interop.xmlbus.com:7002/WSDLCIient/index.html ; 

• XMethods WSDL Analyser : http://www.xmethods.com/ve2/Tools.po. 

Documents 

A Busy Developers Guide to WSDL 1.1 : http://radio.weblogs.com/0101679/stories/2002/02/15/aBusyDevelopers- 
GuideToWsdl11.html. 

Using WSDL in a UDDI Registry 1.08: http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp- 
using-wsdl-v 108-20021 110.pdf. 
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Les chapitres 7, 8 et 9 ont permis de montrer comment echanger des services entre differents processus. 
La maniere de decrire ces services et de formaliser leurs interfaces a ensuite ete exposee dans le 
chapitre 10. Le present chapitre et le suivant vont illustrer comment publier ces services et les rendre 
accessibles a une communaute de « consommateurs » de services plus ou moins etendue. 

Les precurseurs 

Cette question de la publication de services et de la decouverte de ces memes services avait deja ete 
abordee par deux precurseurs : Sun Microsystems et Hewlett-Packard. 

Sun Microsystems Jini 

Des 1998, Sun Microsystems proposait son architecture de reseau Jini (voir site de reference Jini : 
http://www.sun.com/jini). Cette infrastructure de services offrait une API de publication (join) d'un 
service vers un ou plusieurs services de consultation (lookup), accessibles a partir de processus 
clients via une API de decouverte (discover). Lorsqu'il etait localise, le service recherche (en pratique, 
un proxy service Java) etait recupere par le client (receive) et utilise (use) directement sans aucune 
nouvelle interaction avec les services de consultation de 1' infrastructure. 

Cette architecture est finalement restee relativement confidentielle et n'a pas connu le succes escompte. 
Diverses raisons permettent d'expliquer ce quasi-desinteret. Lune d' entre elles est la trop forte adhesion 
de cette architecture au langage Java. En effet, les services sont publies sous forme de proxy-objets 
Java et les interactions avec les services de consultation sont realisees via F utilisation du protocole 
proprietaire RMI (Remote Method Invocation). En corollaire, Futilisation de RMI restraint Futilisation 
de cette architecture au domaine intranet, du fait notamment des reticences des administrateurs reseaux 
a ouvrir des ports specifiques dans les logiciels pare-feu (firewalls). 
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Cette infrastructure n'en reste pas moins interessante et vient d'etre mise a profit par Macromedia, 
d'une maniere tres originale, pour assurer la gestion en cluster de son nouveau serveur d' applications 
Java JRun 4.0 (voir annonce de disponibilite immediate du produit : http://www.macromedia.com/macromedia 
/proom/pr/2002/jrun4_launch. html) . 

Hewlett-Packard e-Speak 

Presque simultanement, Hewlett-Packard publiait en 1999 son architecture de services e-Speak (voir 
site de reference e-Speak : http://www.e-speak.hp.com), issue des travaux d'un projet de recherche initie 
en 1995 aux HP Labs. Cette architecture est la premiere a avoir formalise le concept de service Web. 
Une entite commerciale dediee fut constitute des 1998 et le produit commercialise a partir de l'annee 
suivante. 

Cette architecture s'appuyait notamment sur l'interoperabilite de service a service via des mecanismes 
d'enregistrement, de decouverte et d'interaction de services Web dynamiques. L'acces aux services 
Web publies dans un annuaire de services etait possible via deux modeles : le Network Object Model 
(NOM) ou le Document Exchange Model (DEM). Le Network Object Model permettait de rendre 
accessibles des systemes applicatifs patrimoniaux {legacy systems), tels que des composants Enterprise 
JavaBeans (EJB) par exemple, a travers Internet. Le Document Exchange Model autorisait l'echange 
de documents XML via le Web de maniere faiblement couplee. Ces echanges etaient pris en charge 
par la librairie J-ESI (Java e-Speak Service Interface) via un protocole de messagerie et de transport 
proprietaire. 

La specification e-Speak faisait appel au concept de « vocabulaires » pour formaliser les aspects 
metier d'un service. Ces vocabulaires constituent 1' equivalent des specifications XML sectorielles 
definies actuellement par des organismes de normalisation ou des organisations professionnelles lies 
a des secteurs industriels verticaux. Par exemple, la notion de contrat e-Speak est equivalente a celle 
de service type UDDI (voir concept tModel plus loin dans ce chapitre). 

La plate-forme e-Speak s'appuyait sur la specification SFS (Services Framework Specification) pour 
creer, decrire et deployer des services Web. La definition et F interaction des services Web etaient 
notamment decrites via le langage CDL (Conversation Definition Language), equivalent au langage 
WSDLd'aujourd'hui. 

Le principal defaut de cette architecture est, tout comme celui de 1' architecture de reseau Jini de Sun 
Microsystems, d'avoir ete concue trop tot, juste avant l'explosion de la galaxie XML et 1' apparition 
de ses nombreux langages de normalisation derives. A contrario, les equipes de Hewlett-Packard, par 
cette avance considerable acquise dans le domaine des echanges via Internet, beneficient d'une forte 
experience et se sont deja familiarises avec les differents concepts formalises par les nouvelles speci- 
fications apparues depuis 1998 et plus particulierement UDDI. Ces equipes se sont attelees a une 
reformulation de l'offre e-Speak, maintenant promue sous le nom de Web Services Platform (voir 
http://www. hp. com/go/webservices) . 

Cependant, Hewlett-Packard a decide de se separer d'une partie du portefeuille de produits de sa division 
HP Middleware, qui comporte entre autres la plupart des logiciels dedies au marche emergent des 
services Web. Cette orientation a ete confirmee par 1' annonce de 1' arret des operations sur le nceud de 
l'annuaire public UDDI (UBR) exploite par Hewlett-Packard, arret fixe a la date du 23 juillet 2002, 
comme le confirmait le communique affiche sur la page d'accueil de l'annuaire UDDI de Hewlett- 
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Packard, auparavant accessible a l'adresse https://uddi.hp.com. Cette decision semble avoir ete prise tres 
rapidement, car cet arret est intervenu juste apres l'annonce par le consortium UDDI du demarrage de 
l'exploitation en production des nceuds de l'annuaire public en version 2.0 (dont celui de Hewlett- 
Packard, exploite conjointement avec IBM, Microsoft et SAP au sein de FUBR). 



UDD1 1.0 et 2.0 

La constitution du projet UDDI (Universal, Description, Discovery and Integration) a ete annoncee 
le 6 septembre 2000 a San Francisco par un groupe de trente-six societes (voir annonce : http://www 
. uddi. org/uddipr09062000.html) . 



Initiateurs 

American Express, Andersen Consulting, Ariba, Bowstreet, Cargill, Clams, Commerce One, CommerceQuest, 
Compaq Computer, CrossWorlds Software, Dell Computer, Descartes, Extricity Software, Fujitsu, Great Plains, i2, 
IBM, Internet Capital Group, Loudcloud, match21, Merrill Lynch & Co, Microsoft, New Era of Networks (NEON), 
Nortel Networks, NTT Communications, Rational Software, RealNames, Sabre Holdings, SAP, Sun Microsystems, 
TIBCO Software, Ventro, Versata, VeriSign, VerticalNet et webMethods constituent le noyau initial d'entreprises qui 
ont annoncees leur soutien et leur collaboration a ce projet. 



Les societes Ariba, IBM et Microsoft sont plus precisement a Forigine de cette initiative. La collabo- 
ration entre ces trois entreprises, dans le cadre de partenariats bilateraux, en constitue le point de 
depart, plus particulierement : 

• la collaboration entre Ariba et IBM dans le secteur d'activite du business-to-business (B2B) et des 
places de marche electroniques (e-marketplaces) ; 

• la collaboration entre Ariba et Microsoft autour du serveur BizTalk et de la specification cXML ; 

• la collaboration entre Microsoft et IBM autour du langage XML et de la specification SOAP. 

La mise en place de ce projet constitue une reponse a la montee en puissance du commerce electronique 
et plus specialement de Factivite business-to-business (B2B) sur Internet. Des besoins grandissants 
en matiere d' integration de processus metier entre les differents acteurs de ces nouveaux marches 
sont apparus et ont induit la necessite de rechercher des solutions appropriees. 

Ce projet doit par ailleurs etre replace dans les perspectives ouvertes par F apparition d'une nouvelle 
categorie d' acteurs dans le paysage Internet : les places de marche electroniques. La reference a UDDI 
dans le communique de presse consacre a Finteroperabilite logicielle publie le 19 septembre 2000 par 
F Alliance E-Marketplace (IBM, i2 et Ariba) en est une bonne illustration (voir communique : http://www.anba 
.com/company/news.cfm?pressid=407&archive=1). Des le depart, le projet est soutenu par des acteurs 
importants de la normalisation dans ce domaine. C'est le cas, par exemple, du consortium RosettaNet qui 
annonce, le 25 avril 2001, la publication de ses quatre-vingt-trois processus metier standards PIP (Partner 
Interface Process) dans l'annuaire public (voir annonce : http://www.rosettanet.org/rosettanet/Rooms/DisplayPages 
/LayoutDoc?PressRelease=com.webridge.entity.Entity%5BOID%5B49D79CCA9D39D511BD97009027E33DD8%5D%5D). 

Le site de reference du projet UDDI est localise a l'adresse http://www.uddi.org. Ce site contient F ensemble 
des documents de specification issus des travaux de ce groupe de travail. 
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Deux documents presenters et introduisent les elements fondateurs de cette specification : 

• V Executive White Paper, qui introduit les origines et les principes de cette nouvelle specification (voir 
http://www.uddi.org/pubs/UDDI_Executive_White_Paper.pdf) ; 

• le Technical White Paper, qui presente les concepts et 1' architecture technique generate qui 
constitueront les fondations des logiciels destinees a implementer cette specification (voir http://www 
. uddi. org/pubs/lru_UDDI_ Technical_ White_Paper.pdf) . 

Le document de presentation (voir http://www.uddi.com/pubs/UDDI_Overview_Presentation.ppt) du projet UDDI 
fournit un apercu global de l'entreprise et du planning de realisation. 

La pile de protocoles 

La specification UDDI definit une architecture de communication et d'interoperabilite de services qui 
s'appuie sur des couches techniques deja normalisees ou en voie de normalisation. Cette architecture est 
materialisee par la pile d'interoperabilite presentee figure 11-1. 



Pile 
d'interoperabilite 



Protocoles d'interoperabilite de | 
service universel (a venir) 

Universal Description, 
Discovery Integration (UDDI) 



Protocole SOAP (Simple Object | 
Access Protocol) 



Processeur XML (Extensible 
Markup Language) 



Protocoles Internet standards 
(HTTP, TCP-IP) 



Figure 11-1 

Pile d'interoperabilite de I' infrastructure Web vue par le consortium UDDI. 

Cette pile d'interoperabilite s'appuie sur l'exploitation des protocoles Internet standards (voir chapitre 5 
« Fondations des services Web - Les protocoles Internet »). Les messages echanges, via ces protocoles 
de transport, utilisent le format XML (voir chapitre 6 « Bases des services Web - Technologies XML »). 
Un annuaire UDDI est accessible par l'intermediaire du protocole SOAP (voir chapitre 7 « Echanger 
avec un service - Format d'echange », chapitre 8 « Echanger avec un service - Mecanismes de 
codage » et chapitre 9 « Echanger avec un service - Styles d'echange »). L API UDDI est un service 
Web decrit au format WSDL (voir chapitre 10 « Decrire un service ») qui permet d'acceder a un 
annuaire UDDI via 1' utilisation du protocole SOAP. 

La specification UDDI prevoit egalement que d'autres protocoles d'interoperabilite de plus haut niveau, 
non encore definis a ce jour, s'appuieront sur la couche UDDI pour offrir un niveau de service universel. 
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Les structures de donnees 

La specification UDDI organise F information sur les services Web en trois categories : 

• les pages blanches : adresses, contacts et identifiants connus de Fentreprise (au sens large : entreprise 
commerciale, administration, agence gouvemementale, association, organisation a but non lucratif. . .) ; 

• les pages jaunes : categories industrielles fondees sur des taxonomies standards (produits, entreprises, 
geographiques) ; 

• les pages vertes : references techniques sur les services offerts par Fentreprise (references a des 
specifications de services Web, references vers differentes ressources). 

Le modele d'information UDDI correspondant, specifie sous forme de schema XML, defrnit cinq types 
de structures de donnees. La figure 11-2 decrit les relations entre ces structures : 



businessEntity 



publisherAssertion 



T 




Figure 11-2 

Relations entre les principales structures de donnees UDDI. 



tModel ^™ 



M J relation de contenance 

(2) relation de contenance 

(3) relation de reference 
(4J relation de reference 



Les cinq types structures, definis par la specification UDDI 2.0, sont : 

• le type entite metier (Business Entity) : equivalent des pages blanches (existe depuis UDDI 1 .0) ; 

• le type service metier (Business Service) : equivalent des pages jaunes (existe depuis UDDI 1.0) ; 

• le type modele de liaison (Binding Template) : equivalent des pages vertes (existe depuis UDDI 1.0) ; 

• le type service type (tModel) : descriptions de specifications de services ou de taxonomies referencees 
par les modeles de liaison (existe depuis UDDI 1 .0) ; 

• le type assertion d' administrates (Publisher Assertion) : descriptions de relations entre entites 
metier, affirmees par Fadministrateur (« editeur ») de Fune des entites metier concernees (nouveau 
type introduit par UDDI 2.0). 
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Dans ce schema, les entites metier et les services types constituent les deux racines du graphe 
d'objets representes. Les entites metier sont referencees dans l'annuaire. Elles sont susceptibles 
d'offrir des services metier qui leur sont propres (0 a n services). Cette offre est materialisee par la 
relation de contenance n° 1 . Les services metier relativement « simples », tels que les services accessibles 
par des moyens traditionnels comme le telephone, le fax, etc. sont entierement decrits par leur propre 
structure de donnees. En revanche, des services metier plus elabores peuvent constituer l'implemen- 
tation de services types dermis et normalises par des organismes de normalisation, des syndicats ou 
des organisations professionnelles, etc. Ces implementations sont specifiers par des modeles de liaison 
(0 a n modeles de liaison) qui decrivent les modalites de 1' implementation realisee. Ces specifications 
sont representees par la relation de contenance n°2. Les services types implemented par un service 
metier particulier sont references via les modeles de liaison. Ce lien apparait a travers le lien de refe- 
rence n°3. Enfin, les entites metier peuvent etre liees selon differentes relations. Ces relations sont 
representees sous forme d'assertions exprimees par les administrateurs des entites liees. Ces assertions 
referencent les entites concemees et sont illustrees par le lien de reference n°4. 

Ces differentes structures d' information sont precisement decrites et analysees dans le document de 
reference de la specification UDDI Version 2.03 Data Structure Reference (voir http://uddi.org/pubs/ 
DataStructure-V2.03-Published-20020719.pdf). Lancien document de reference des structures d'informa- 
tion UDDI 1.0 peut toujours etre consulte (voir UDDI Data Structure Reference VI. : http://uddi.org/ 
pubs/DataStructure- V1 . 00-Published-20020628.pdf) . 

L'acces a l'annuaire 

L'annuaire UDDI est accessible de deux manieres : 

• via un navigateur Web qui dialogue avec une application Web dediee, interface specifique a 
l'annuaire accede ; 

• ou bien par programme, en utilisant VAPI (Application Programming Interface) definie par la 
specification. 

L'API comporte deux groupes de fonctions : 

• les fonctions de recherche (Inquiry API) : navigation, recherche et consultation des informations 
de l'annuaire ; 

• les fonctions de publication (Publishing API) : publication, creation, modification ou suppression 
des informations de l'annuaire. 

II existe d'autres fonctions dans l'API UDDI, mais celles-ci sont plutot dediees a l'exploitation de 
l'annuaire (par exemple, l'API de replication entre annuaires). 

Cette API de programmation est definie en WSDL et utilise le protocole SOAP pour interagir avec 
l'annuaire. En effet, elle est elle-meme definie comme un service Web. 

Tous les appels de l'API sont synchrones. Le resultat d'une operation effectuee sur l'annuaire est 
immediatement retourne. 

L'acces a l'annuaire destine a rechercher des informations est entierement anonyme. Aucune 
identification n'est necessaire pour ce type d'activite. En revanche, toute mise a jour des informations 
d'un annuaire requiert une phase d' identification et d'autorisation de la personne ou du processus qui 
se connecte. Toutes les fonctions de publication sont mises en ceuvre via l'utilisation du protocole HTTPS. 
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L'interface de programmation (API) 

L'API est done decomposed en plusieurs sous-ensembles qui regroupent des fonctions homogenes 
dediees a des domaines specifiques. 

Ces sous-ensembles sont non seulement eux-memes implemented comme des services Web, mais ils 
sont de plus autodecrits. Ils sont enregistres comme des services types (tModels) dans une implemen- 
tation d'annuaire UDDI. Ces services types peuvent etre retrouves via le nom generique prefixe uddi-org. 

Les services types qui correspondent aux deux API precedentes sont respectivement enregistres sous 
les references : 

• uddi-org:inquiry(cleuuid:4cd7e4bc-648b-426d-9936-443eaac8ae23) pour l'APIde recherche UDDI 1.0. 
La description au sens WSDL de ce service est situee a Fadresse http://www.uddi.org/wsdl/inquire_v1.wsdl ; 

• uddi-org:publication (cle uin'd:64c756dl-3374-4e00-ae83-eel2e38fae63) pourl'API de publication 
UDDI 1.0. La description au sens WSDL de ce service est situee a l'adresse http://www.uddi.org/wsdl/ 
publish_v1 .wsdl ; 

• uddi-org:inquiry_v2 (cle Iiuid:acl04dcc-d623-452f-88a7-f8acd94d9b2b) pour l'API de recherche 
UDDI 2.0. La description au sens WSDL de ce service est situee a l'adresse http://uddi.org/wsdl/ 
inquire_v2.wsdl ; 

• uddi-org:publication_v2 (cle uuid:a2f36b65-2d66-4088-abc7-914d0e05eb9e) pour l'API de publi- 
cation UDDI 2.0. La description au sens WSDL de ce service est situee a l'adresse http://uddi.org/ 
wsdl/publish_ v2. wsdl. 

Si, dans l'une des implementations de l'annuaire public de reference gere par IBM, Microsoft, NTT 
Communications et SAP, on effectue une recherche des entites metier qui implementent ces quatre 
services types, une liste de deux entites metier est retournee a ce jour : Microsoft UDDI Business 
Registry Node et SAP AG. Ces societes represented deux des quatre entites metier qui gerent 
1' implementation de reference de la specification UDDI. 



Identification des structures de donnees UDDI 

Les structures de donnees UDDI sont identifies par des cles uniques, generees automatiquement par l'annuaire, 
lors de la premiere sauvegarde de ces structures. Ces cles sont constitutes par des « identifiants universels 
uniques » (UUID ou Universally Unique Identifier), quelquefois egalement nommes « identifiants globaux 
uniques » (GUID ou Globally Unique Identifier). 

Ces cles presentent une structure de chaine standardisee de caracteres hexadecimaux, dont I'algorithme de 
generation tres precis permet d'eviter la generation de cles identiques. La structure de la cle, ainsi que I'algorithme 
de generation, sont standardises par I'ISO sous le numero de standard ISO/IEC 1 1 578:1 996 (voir information techno- 
logy - Open Systems Interconnection - Remote Procedure Call (RPC) http://www.iso.ch/iso/en/CatalogueDetail- 
Page. CatalogueDetail?CSNUMBER=2229& ICS 1 =35& ICS2= 1 00& ICS3=70) . 

La specification Operateur (voir la section « Nouveautes introduites par UDDI 2.0 » plus loin dans ce chapitre) 
explore de plus pres la gestion des cles UUID du point de vue d'un operateur. Elle reference egalement le document 
de travail UUIDs and GUIDs de I'lETF (voir http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt). 
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Les URL d'acces aux implementations IBM et Microsoft 

Comment acceder a ces implementations de maniere programmatique ? Quel est le point d'acces qui 
permet de les activer sur Internet ? 

La reponse est tres simple. Cette premiere recherche peut etre affinee par programme, en utilisant la 
fonction find_service de l'API de recherche par exemple. Une autre alternative consiste a se servir 
de 1' interface Internet propose par les sites de Microsoft ou d'IBM et a balayer ainsi les services 
proposes par ces deux entites metier. II est possible de retrouver de cette maniere les services fournis 
par ces deux operateurs qui implementent les API qui nous interessent. 

Par exemple, pour l'entite metier Microsoft UDDI Business Registry Node, si Ton inspecte de plus 
pres le service metier intitule UDDI Services (cle bd22c024-5f93-43d0-b09e-eeal88f 19768), on peut 
remarquer la liste des points d'acces (Access Points) qui sont utilisables pour ce service. Ce sont ces 
points d'acces qui doivent etre utilises pour acceder de maniere programmatique a l'annuaire UDDI 
maintenu par Microsoft, plus particulierement : 

• l'adresse https://uddi.microsoft.com/publish permet d'acceder a l'annuaire de production par l'API de 
publication (UDDI 1.0 ou 2.0) ; 

• l'adresse http://uddi.microsoft.com/inquire autorise 1' acces a l'annuaire de production via l'API de recherche 
(UDDI 1.0 ou 2.0); 

Curieusement, les points d'acces a l'annuaire de test de Microsoft ne sont plus publies dans l'annuaire 
UDDI, mais peuvent etre utilises, ainsi : 

• l'adresse https://test.uddi.microsoft.com/publish propose un acces a l'annuaire de test via l'API de 
publication ; 

• l'adresse http://test.uddi.microsoft.com/inquire offre un acces a l'annuaire de test par l'API de recherche. 



Details sur les adresses proposees par le service de Microsoft 

Les adresses qui permettent d'acceder a l'annuaire de test commencent par la chaine de caracteres test. 

Les adresses d'acces aux annuaires (annuaire de test et annuaire de production) font appel au protocole HTTPS 

comme le prevoit la specification. 

Ce sont les deux adresses qui permettent d'acceder a l'annuaire de production de I'implementation de reference 

de Microsoft qui ont ete utilisees pour executer les exemples suivants afin d'illustrer le comportement des differentes 

fonctions de l'API de recherche et de l'API de publication. 



Si Ton poursuit cette recherche sur les services proposes par l'entite metier IBM Corporation, on 
peut decouvrir deux services metier interessants : 

• le service Publish to the UDDI Business Registry (cle 892d41b0-3aaf-lld5-80dc-002035229c64) ; 

• le service UDDI Business Registry inquiry (cle 892a3470-3aaf-lld5-80dc-002035229c64). 

On peut ici remarquer une difference de choix d' implementation entre IBM et Microsoft. Microsoft a 
regroupe l'ensemble des points d'acces a son implementation sous un seul service metier. En revanche, 
IBM a choisi de dedoubler ses points d'acces en deux services metier en fonction de la nature de 
l'API prise en charge (recherche et publication). Ceci montre la souplesse autorisee par le schema 
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de donnees de la specification et la marge de manoeuvre laissee aux administrateurs UDDI pour 
organiser l'offre de services de leur societe. 

Si Ton observe plus precisement les points d'acces presents a Finterieur des deux services metier 
d'IBM, on trouve pour le service Publish to the UDDI Business Registry : 

• Fadresse https://www-3.ibm.com:443/services/uddi/protect/publishapi qui permet d'acceder a Fannuaire de 
production par 1' API de publication (acces par programme via le protocole SOAP) ; 

• Fadresse https://www.ibm.com/services/uddi/protect/publish qui autorise Faeces a Fannuaire de production 
via FAPI de publication (acces par navigateur Web) ; 

• Fadresse https://www-3.ibm. com:443/services/uddi/testregistry/protect/publishapi qui propose un acces a 
Fannuaire de test via FAPI de publication (acces par programme via le protocole SOAP) ; 

• Fadresse https://www.ibm.com/services/uddi/testregistry/protect/publish qui offre un acces a Fannuaire de 
test par FAPI de publication (acces par navigateur Web). 

De meme, pour le service UDDI Business Registry inquiry, les points d'acces a Fannuaire proposes 
sont : 

• Fadresse http://www-3.ibm.com/services/uddi/inquiryapi qui permet d'acceder a Fannuaire de production 
par FAPI de recherche (acces par programme via le protocole SOAP) ; 

• Fadresse http://www.ibm.com/services/uddi/findqui autorise Faeces a Fannuaire de production via FAPI 
de recherche (acces par navigateur Web) ; 

• Fadresse http://www-3.ibm.com/services/uddi/testregistry/inquiryapi propose un acces a Fannuaire de test 
via FAPI de recherche (acces par programme via le protocole SOAP) ; 

• Fadresse http://www.ibm.com/services/uddi/testregistry/findoffre un acces a Fannuaire de test par FAPI de 
recherche (acces par navigateur Web). 

A Fanalyse, ces deux series d'adresses montrent qu'IBM a choisi de presenter sous le meme service 
F ensemble des points d'acces a son implementation d'annuaire, que ceux-ci permettent d'y acceder 
de maniere programmatique (via le protocole SOAP) ou au moyen de Finterface visuelle Web (via un 
navigateur Web). 

Seules les adresses pour lesquelles a ete ajoutee la mention « acces par programme en mode SOAP » 
peuvent etre utilisees pour acceder par programme a F implementation de Fannuaire d'IBM, que ce 
soit a la zone test ou production de Fannuaire. 

Si Fon regarde de plus pres, on peut observer que Microsoft n'a pas enregistre les points d'acces a 
son implementation par Finterface visuelle Web. 



Details sur les adresses proposees par le service d'IBM 

Les adresses qui permettent d'acceder a I'annuaire de test comportent une chaine de caracteres /testregi stry 
derriere I'expression /uddi dans I'URL. 

A llnstar des adresses fournies par Microsoft, les adresses d'acces aux annuaires (annuaire de test et annuaire de 
production) d'IBM font appel au protocole HTTPS comme le prevoit la specification. 
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Les nouveautes introduites par UDDI 2.0 

La mise en ligne officielle des premieres implementations UDDI 1.0 de Microsoft et IBM a ete realisee 
le 2 mai 2001 (voir annonce : http://www.uddi.org/uddipr05022001.html). A cette date, les membres de 
l'UBR (UDDI Business Registry), qui represente les nceuds d'acces a Fannuaire public UDDI, ne 
sont represented que par deux operateurs : IBM et Microsoft. 

Des cette annonce, Hewlett-Packard evoque la signature d'un accord avec les deux premiers operateurs, 
arm de devenir membre de l'UBR. La decision de la participation de Hewlett-Packard aux travaux de 
l'initiative UDDI remonte a la fin de l'annee 2000 (voir communique : http://www.hp.com/hpinfo/ 
newsroom/press/26oct00b. htm) . 

Cette mise en ligne porte sur des implementations conformes a la specification UDDI version 1 .0. La 
meme annonce precise que la version 2.0 de la specification approche de sa completude et qu'elle est 
en cours de revue, a cette date, par les membres de la communaute UDDI. 

La version 2.0 publique de la specification UDDI est publiee le 18 juin 2001 (voir annonce : http://www 
.uddi.org/uddipr06182001 .html). Les principales evolutions concernent : 

• la prise en compte de structures d' organisation complexes (liens entre entites metier de natures 
diverses : societe mere, filiales, departements, divisions, etc.) ; 

• une meilleure prise en charge de l'internationalisation ; 

• un ajout de schemas supplementaires de categorisation et d' identification des structures de donnees 
UDDI (entites metier, services metier, services types) ; 

• l'introduction de fonctionnalites de recherche plus riches. 

Cette annonce informe egalement de la reunion de la communaute UDDI a Atlanta, durant la meme 
semaine, arm de definir les besoins de la future version 3.0 de la specification. 

La version 2.0 de la specification UDDI est materialisee par revolution des documents de reference 
publies lors de la mise en ligne de la version 1.0. 

Les documents initiaux : 

• UDDI Programmer's API 1.0 (voir http://uddi.org/pubs/ProgrammersAPI-V1.01-Published-20020628.pdf) ; 

• UDDI Data Structure Reference 1.0 (voir http://uddi.org/pubs/DataStructure-V1.00-Published-20020628.pdf) ; 
ont ete remplaces par les nouvelles versions : 

• UDDIVersion 2.04 API Specification (voir http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf) ; 

• UDDI Version 2.03 Data Structure Reference (voir http://uddi.org/pubs/DataStructure-V2.03-Published- 
20020719.pdf). 

La publication de la version 2.0 de la specification UDDI s'est egalement traduite par F apparition de 
nouveaux documents de specification : 

• UDDI Version 2.03 Replication Specification (voir http://uddi.org/pubs/Replication-V2.03-Published- 
20020719.pdf) : ce document decrit le processus et F interface de programmation necessaires a la 
mise en ceuvre de la replication des annuaires entre operateurs de sites UDDI ; 

• UDDI Version 2.01 Operator's Specification (voir http://uddi.org/pubs/Operators-V2.01-Published- 
20020719.pdf) : ce document etablit le comportement attendu et les parametres de fonctionnement 
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requis de la pail d'un operateur de site UDDI, que ce soit du point de vue des utilisateurs de la 
communaute UDDI ou du point de vue des autres operateurs ; 

Providing a Taxonomy for Use in UDDI Version 2 (voir http://www.oasis-open.org/committees/uddi-spec/ 
doc/tn/uddi-spec-tc-tn-taxonomy-provider-v1 00-2001 071 7.pdf). 



Specifications Replication et Operateur 

Ces deux specifications sont nouvelles par rapport a la version 1 .0 d'UDDI. Elles formalisent le processus de 
replication entre operateurs de noeuds UDDI d'une part, et le comportement attendu d'un operateur de noeud 
d'autre part. Ces specifications relevent plutot d'une problematique d'administration et d'exploitation : il n'est pas 
necessaire de les connaitre pour developper des outils d'acces aux annuaires UDDI. 
Ces specifications ne sont done pas abordees dans ce chapitre, ni dans le suivant, car elles sortent du cadre de 
cet ouvrage. Cependant, elles sont bien evidemment importantes pour un concepteur en charge du developpe- 
ment d'une implementation serveur de UDDI. 

L'intention premiere de la publication de ces specifications n'etait pas de formaliser un processus de replication 
entre implementations UDDI privees. D'ailleurs, les implementations privees actuelles (IBM, Microsoft, etc.) ne 
prennent pas en charge cette fonctionnalite. Cependant, il est vraisemblable que revolution des architectures 
UDDI implantees dans les entreprises exigera, tot ou tard, la prise en charge de cette caracteristique et la verifica- 
tion de I'interoperabilite entre implementations heterogenes. 



L'acces aux sites de tests (beta) de la version 2.0 est possible des le 19 novembre 2001 (voir annonce : 
http://www.uddi.org/uddipr1 1 192001 .htm). Les membres de FUBR sont maintenant au nombre de quatre : 
les operateurs historiques IBM et Microsoft, auxquels se sont joints Hewlett-Packard et SAP. SAP 
est devenu operateur de FUBR un mois auparavant (voir communique : http://www.sap.com/company/ 
press/press.asp ?presslD=629) . 

Chacun de ces operateurs publie une URL d'acces a son propre site de tests. Ceux-ci cohabitent bien 
entendu avec les sites de « production » UDDI 1.0, tenus par IBM et Microsoft. Au 19 novembre 
2001, Finitiative UDDI est deja soutenue par plus de trois cents entreprises, et plus de sept mille entites 
metier sont enregistrees dans Fannuaire de production. 

Le 20 decembre 2001, Hewlett-Packard, IBM et SAP annoncent leur soutien a F implementation 
cliente Java UDDI4J qui a evolue pour prendre en charge la version UDDI 2.0 (voir annonce http:// 
www-124.ibm.com/developerworks/oss/uddi4j). Cette implementation de FAPI UDDI est utilisee plus loin 
dans ce chapitre, ainsi que dans le chapitre suivant, pour illustrer le fonctionnement des serveurs UDDI. 



UDDI 2.0 etWS-l Basic Profile 1.0 

La premiere version du profil de base defini par le WS-I (Web Services Interoperability Organization) a adopte la 
specification UDDI, et plus particulierement la version 2.0, pour 1'implementation de la fonctionnalite de decouverte 
de services metier dans une architecture orientee services (voir chapitre 17 : « Le defi de I'interoperabilite »). 
Les recommandations liees a I'usage de la specification UDDI sont definies dans la section « Service Discovery » 
(voir http://ws-i.Org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm#discovery) de la version de travail, datee du 
8 octobre 2002, de la version 1 .0 du profil de base. Ces recommandations portent sur des regies de publication a 
destination d'un annuaire UDDI : elles sont abordees dans le chapitre 12, qui traite de I'API de publication. 
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La recherche dun service 

L'API de recherche (Inquiry API) est presentee en detail dans le document de reference UDDI 
Version 2.04 API Specification (voir http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf). 

Cette API comporte neuf fonctions (initialement disponibles en version 1 .0) : 

fonction f ind_binding : cette fonction recherche l'existence d'une liaison specifique a l'interieur 
d'un service metier. Elle renvoie un message bi ndi ngDetai 1 . 

fonction find_business : cette fonction recherche l'existence d'information sur une ou plusieurs 
entites metier. Elle renvoie un message business List. 

fonction find_service : cette fonction recherche l'existence de services metier specifiques a 
l'interieur d'une entite metier. Elle renvoie un message servi ceLi st. 

fonction f i nd_tModel : cette fonction recherche l'existence d'un ou plusieurs services types. Elle 
renvoie un message tModel List. 

fonction get_bi ndi ngDetai 1 : cette fonction recherche une information complete sur une liaison 
specifique a l'interieur d'un service metier. Elle renvoie un message bi ndi ngDetai 1 . 

fonction get_businessDetail : cette fonction recherche une information complete sur une ou 
plusieurs entites metier. Elle renvoie un message businessDetai 1 . 

fonction get_businessDetailExt : cette fonction recherche une information etendue sur une ou 
plusieurs entites metier. Elle renvoie un message businessDetai 1 Ext. 

fonction get_serviceDetail : cette fonction recherche une information complete sur un service 
metier specifique a l'interieur d'une entite metier. Elle renvoie un message servi ceDetai 1 . 

fonction get_tModel Detail : cette fonction recherche une information complete sur un service 
type. Elle renvoie un message tModel Detai 1 . 

La version 2.0 de 1' API a ajoute une dixieme fonction : 

fonction find_relatedBusinesses : cette fonction recherche des entites metier associees a une 
entite metier donnee. Elle renvoie un message relatedBusinessesList. 

La mise en ceuvre de chacune des fonctions de cette API est illustree ci-apres a l'aide d'un ou de 
plusieurs exemples. Ces exemples utilisent l'annuaire de production de Microsoft (implementation 
UDDI cote serveur : http://uddi.microsoft.com). En ce qui concerne la partie cliente UDDI, celle-ci met 
en ceuvre le langage Java et plus particulierement 1' implementation UDDI4J d'IBM. 

Cette implementation d'UDDI est presente dans l'environnement d' execution IBM WSTK (Web 
Services Tool Kit), disponible sur le site d'IBM alphaWorks dedie aux technologies emergentes a 
l'adresse http://www.alphaworks.ibm.com/tech/webservicestoolkit, depuis la version 2.1. Ce paquetage est 
egalement disponible separement sur le site d'IBM developerWorks dedie aux projets Open Source, 
dans la section des projets Open Source sous licence IBM Public License, a l'adresse http://oss.software 
.ibm.com/developerworks/projects/uddi4j. 

Les tests ont ete realises avec 1' implementation UDDI4J presente dans la version 3.2.2 de la boite a 
outils WSTK d'IBM. Cette implementation prend en charge la version 2.0 de la specification UDDI. 
Elle est capable de fonctionner avec plusieurs implementations du protocole de transport SOAP : 
Apache Axis, Apache SOAP et Hewlett-Packard SOAP. 
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Nous avons retenu 1' implementation Apache Axis, deja presente dans la boite a outils WSTK d'IBM. 

Les elements de syntaxe communs 

Certains attributs ou elements sont communs a plusieurs fonctions de l'API de recherche. En voici 
quelques-uns : 

• L'attribut maxRows est optionnel et permet de limiter le nombre d'elements renvoyes dans la liste 
resultante d'une requete de type find. Si le resultat retourne est incomplet du fait de l'application 
de cette contrainte (ou d'une limitation specifique au site de l'operateur de Fannuaire utilise), le 
message renvoye par la requete contient un attribut truncated dont la valeur est positionnee a true. 

• L' element f 1 ndQual 1 f i ers est une collection de qualificateurs de recherche (ou filtres) qui peuvent 
etre utilises pour modifier le comportement standard d'une requete de type find. Cet element est 
optionnel et peut etre mis en ceuvre conjointement a d'autres arguments de la requete. 

• L' element tModelBag permet de specifier une liste de cles de tModels qui peut etre utilisee pour 
modifier le comportement standard d'une requete de type find (sauf find_tModel). Les structures 
de donnees tModel s sont referencees par les liaisons des services metier, via la structure de donnees 
de type bindingTemplate (par 1' intermediate de sa sous-structure tModel Instancelnfo ; voir 
figure 1 1-2). Ainsi, la liste renvoyee par la requete est filtree et ne comporte que les entites metier, les 
services metier ou les liaisons qui referencent l'ensemble des cles de tModel s passees en parametre 
(« et » logique). L'ordre des cles de tModel s est indifferent. 

• L'element i denti f i erBag permet de preciser une liste d'identificateurs metier qui correspondent aux 
entites metier ou services types recherches : la liste retournee comprend les structures de donnees 
identifiees par l'un ou 1' autre des identificateurs (« ou » logique). 

• L'element category Bag permet de specifier une liste de localisateurs qui determinent des references 
categorielles propres aux entites ou services metier recherches : la liste renvoyee comporte les 
structures de donnees qui sont classees dans chacune des categories precisees (« et » logique). 

La fonction find_binding 

La fonction f i nd_bi ndi ng a pour objectif de rechercher l'existence d'un modele de liaison specifique 
a l'interieur d'un service metier. Cette fonction renvoie un message bindingDetail, constitue de 
structures de donnees de type bi ndi ngTempl ate. 

Syntaxe du message find_binding 

La syntaxe de ce message est la suivante : 

<find_binding serviceKey="ut/7'a l _^ey" [maxRows="nn"] generic="2.0" 

xmlns="urn:uddi-org:api_v2"> 

[<findQualifiers/>] 

<tModelBag/> 
</find_binding> 
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L'attribut serviceKey determine la cle du service metier particulier sur lequel porte la recherche de 
liaisons. Seules les liaisons implementees par ce service metier sont susceptibles de figurer dans la 
liste resultante. 

Le schema de la structure de donnees bindingTemplate, contenue dans le message bindingDetail, se 
presente ainsi : 

<element name="bindingTempl ate" type="uddi :bindingTemplate" /> 
<complexType name="bindingTemplate"> 
<sequence> 

<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 
<choice> 

<element ref="uddi :accessPoint" /> 
<element ref="uddi :hostingRedi rector" /> 
</choice> 

<element ref="uddi :tModel InstanceDetails" /> 
</sequence> 

<attribute name="serviceKey" type="uddi :serviceKey" use="optional " /> 
<attribute name="bindingKey" type="uddi :bindingKey" use="requi red" /> 
</complexType> 

L'exemple ci-apres illustre la maniere d'utiliser les differents elements du message et comment les 
associer pour rechercher des modeles de liaison implemented par un service metier. Ann de trouver 
des exemples supplementaires de mise en oeuvre des arguments findQualifiers et tModelBag, le 
lecteur pourra se referer a la section suivante dans laquelle d'autres utilisations possibles de ces 
elements sont decrites. 

Rechercher un modele de liaison 

Exemple d' utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. binding. BindingTemplate; 

import org.uddi4j . response. BindingDetail ; 

import org.uddi'4j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java .util .Vector; 

public class UDDIFindBindingl { 

public static void main(String[] args) throws Exception { 

Le code suivant active F implementation du protocole de transport a utiliser par la requete, cree 
l'instance de proxy-client UDDI et affecte l'adresse de l'annuaire UDDI auquel seront adressees les 
requetes de recherche. Cette partie du code est identique dans tous les exemples qui suivent : elle sera 
done omise dans les prochaines requetes. 

System. set Property (Trans port Factory. PROPERTY_NAME, 
"org.uddi4j .transport .ApacheAxisTransport") ; 

UDDIProxy proxy = new UDDIProxy( ) ; 

proxy .setlnqui ryURK "http://uddi .microsoft.com/inqui re" ) ; 

Vector tbv = new VectorO; 
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TModelKey tk = new TModel Key( "UUID:64C756Dl-3374-4E00-AE83-EE12E38FAE63") ; 

tbv.addElement(tk) ; 

TModel Bag tb = new TModel BagO; 

tb.setTModelKeyVector(tbv); 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByDateDesc) ; 

fqv.addElement(fq) ; 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BindingDetail bd = proxy .find_binding(fqs, 

"892d41b0-3aaf-lld5-80dc-002035229c64", tb, 0); 

Vector bdv = bd.getBindingTemplateVector( ) ; 
if (bdv.sizeO == 0) { 

System. out. printlnC'no binding(s) found"); 

System. exit(0) ; 
} 

System. out. println(bdv. size( )+" binding(s) found\n"); 
for (int i = 0; i < bdv.sizeO; i++) { 

BindingTempl ate bt = (BindingTempl ate)bdv.elementAt(i ) ; 

System. out. println(bt.getDefaul tOescriptionStringt )) ; 

System. out. println(bt.getBindingKey( ) ) ; 

System.out.println("\n") ; 



) 

Cet exemple montre comment recuperet 1' ensemble des modeles de liaison qui implementent le 
service type uddi-org:publication (cle UUID:64C756Dl-3374-4E00-AE83-EE12E38FAE63) via le service 
metier Publish to the UDDI Business Registry (cle 892d41b0-3aaf-lld5-80dc-002035229c64) propose par 
Fentite metier IBM. Cet ensemble de modeles de liaison est renvoye trie par ordre anti-chronologique 
de mise a jour. 

Les modeles de liaison obtenus correspondent en pratique, l'un a 1' implementation de l'API de 
publication pour acceder a l'annuaire UDDI de production et F autre a F implementation de cette meme 
API de publication pour acceder a l'annuaire UDDI de test. 

Ce programme de recherche restitue le resultat suivant : 

2 binding(s) found 

Publish to UDDI Test registry(SOAP) 

8af57780-4584-lld5-bd6c-002035229c64 

Publish to UDDI Business Registry(SOAP) 

6bda8af0-3aaf-lld5-80dc-002035229c64 
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Utilisation des cles de structures de donnees 

Les cles des structures de donnees UDDI sont constitutes d'identifiants UUID (Universal Unique Identifier) au 
format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX (8-4-4-4-12) dans lequel chaque caractere est une 
valeur hexadecimale comprise dans I'ensemble {A-F,a-f,0-9}. Ces identifiants UUID ne sont pas sensibles a la casse : 
les valeurs minuscules et majuscules des caracteres qui constituent ces identifiants sont equivalentes. 
Les arguments qui referenced des cles de structures de donnees doivent etre passes sous forme d'une chaine de 
caracteres qui respecte ce format (tirets compris). Cette regie generale est valable pour toutes les structures de 
donnees UDDI, a I'exception des structures de type tModel pour lesquelles la valeur de I'identifiant doit etre precedee 
de la chame de caracteres uui d : (URI). 



La fonction find_business 

La fonction find_business permet de rechercher un ou plusieurs elements de type businessEntityen 
fonction de differents criteres. 

Cette fonction renvoie un message businessList. En cas de recherche infractueuse par rapport aux 
criteres de recherche utilises, la liste renvoyee est vide. Dans le cas contraire, le message businessList 
retourne est constitue de structures de donnees de type businesslnfo (forme abregee d'une structure 
de donnees businessEntity), incluses dans une collection businesslnfos. 

Syntaxe du message find_business 

La syntaxe de ce message est la suivante : 






<find_business [maxRows="nn"] generic="2.0" xmlns="urn:uddi-org:api_v2"> 

[<findQualifiers/>] 

[<name/> [<name/>]...] 

[<discoveryURLs/>] 

[<identifierBag/>] 

[<categoryBag/>] 

[<tModelBag/>] 
</find_business> 

Lelement name precise un nom complet ou partiel d'entites metier a rechercher : la liste resultante est 
constituee de toutes les entites dont le nom correspond a cette valeur. La correspondance est evaluee 
en commencant par la gauche pour les noms partiels (pour une langue qui s'ecrit de gauche a droite). 
Le caractere « % » est utilise pour les noms partiels. Par defaut, la recherche est effectuee comme si 
le nom se terminait par - le caractere « % » (nom partiel pour une langue qui s'ecrit de gauche a droite) 
et inversement pour une langue qui s'ecrit de droite a gauche. Les noms de la collection peuvent etre 
qualifies avec l'attribut xml :lang (internationalisation). Si la collection comporte plusieurs noms, la 
liste retournee comprend des entites metier identifiees par l'un ou l'autre des noms (« ou » logique). 

Lelement di scoveryURLs specifie une liste d'adresses URL associees aux entites metier recherchees : 
la liste renvoyee est constituee des entites metier qui correspondent a l'une ou l'autre des adresses 
URL passees en parametres (« ou » logique). 
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Le schema de la structure de donnees businesslnfo, contenue dans le message businessList, se 
presente ainsi : 

<element name="businessInfo" type="uddi :businessInfo" /> 
<complexType name= "business I nfo"> 
<sequence> 

<element ref="uddi :name" maxOccurs="unbounded" /> 

<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 
<element ref="uddi :serviceInfos" /> 
</sequence> 

<attribute name="businessKey" type="uddi :businessKey" use="requi red" /> 
</complexType> 

Les exemples qui suivent montrent comment utiliser ces differents elements du message et si necessaire 
comment les combiner entre eux pour rechercher des entites metier. 

Rechercher des entites metier par le nom 

Premier exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import Java. util .Vector; 

public class UDDIFindBusinessl { 

public static void main(String[] args) throws Exception { 

Vector names = new VectorO; 
names. add(new NameC'IBM") ) ; 
BusinessList bl = proxy .find_business(names, 
null, null, null, null, null, 0); 

Le code suivant est destine a lister le resultat (noms et cles des entites metier renvoyees) de la requete 
adressee a Fannuaire UDDI. Cette partie du code est identique dans tous les exemples de recherche 
d'entites metier qui suivent : elle sera done omise dans les prochaines requetes. 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System.exit(O) ; 
} 

System. out .println(bis.size( )+" business(es) found\n"); 
Vector biv = bis.getBusinessInfoVector( ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 

System. out. printlntbi .getNameString( ) ) ; 

System. out .println(bi .getBusinessKey( )) ; 

System.out.println("\n" ) ; 
} 
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Cet exemple montre comment recuperer F ensemble des entites metier dont le nom commence par 
IBM. II s'agit du comportement par defaut : la fonction verifie la coiTespondance entre la chaine 
textuelle fournie et la partie gauche des entrees de l'annuaire (leftmost match). Voici le resultat 
renvoye a 1' utilisation de ce programme : 

5 business(es) found 

IBM Corporation 
d203311u-3aaf-lld5-80dc-002035229c64 

IBM WSTK Tutorial 
fdfdbba0-a7d3-lld5-a30a-002035229c64 



Differences de comportement entre les implementations des annuaires 

Le meme programme utilise pour acceder a l'annuaire de production d'IBM renvoie une liste legerement differente 

de celle renvoyee par le site de Microsoft. Celle-ci contient les memes entites metier, mais les deux dernieres sont 

inversees. 

Normalement, lorsque la recherche n'est pas qualifiee (absence de qualificateurs de recherche dans la requete), 

la liste resultante est triee de maniere ascendante sur le nom, et par date de modification ascendante a I'interieur 

du nom. 

II ne faut pas perdre de vue que les deux listes peuvent aussi etre differentes du simple fait que l'annuaire est distribue 

et replique a intervalles reguliers. Si une nouvelle entite metier, dont le nom commence par la chaine de caracteres 

IBM, est creee dans ('implementation de l'annuaire d'IBM, cette entite metier ne sera presente qu'apres la 

prochaine replication vers 1'implementation de l'annuaire de Microsoft dans une liste retournee en reponse a une 

requete identique sur le site de Microsoft. 



Si la chaine textuelle fournie avait ete la valeur IBM WSTK, le resultat aurait ete : 
1 business(es) found 

IBM WSTK Tutorial 
fdfdbba0-a7d3-lld5-a30a-002035229c64 

Dans cet exemple, on notera la valeur « » utilisee a la ligne : 

BusinessList bl = proxy .find_business(names, null, null, null, null, 



0); 



Cette valeur correspond a Fattiibut maxRows de Felement f i nd_busi ness de la specification. Lorsque cette 
valeur est fournie, la taille de la liste retournee est limitee a cette valeur. Si nous avions positionne 
cette valeur a « 1 », le resultat de ce programme aurait ete : 



1 business(es) found 



IBM Corporation 
d203311U-3aaf-lld5-80dc-UU2035229c64 
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Utilisation d'un caractere joker 

Le symbole « % » peut etre utilise comme un caractere joker. II peut remplacer tout ou partie de la chaine de 

caracteres du critere de recherche. 

Lorsque toute la chaine de caracteres du critere de recherche est remplacee par le caractere joker et que I'attribut 

maxRows est fixe a 0, le nombre d'entites metier renvoyees par la fonction est limite par ('implementation du 

serveur. 

Pour I'annuaire de production de Microsoft, cette limite est fixee a 1 000 entit.es. Si la valeur de I'attribut maxRows 

est forcee a une valeur superieure a 1 000 unites, cette valeur n'est pas utilisee par I'annuaire et est abaissee 

d'autorite a 1 000 unites. Par exemple, si Ton positionne cette valeur a 250 entries, c'est ce dernier nombre qui est 

pris en compte. Si I'on avait choisi un maximum de 7 500, cette derniere valeur aurait ete abaissee d'autorite a 

1 000 entites par I'annuaire de Microsoft. 

Celui d'IBM ne restitue qu'un maximum de 100 entites. Si la valeur de I'attribut maxRows est forcee a une valeur 

superieure a 100 unites, c'est cette valeur qui est utilisee pour un maximum possible d'unites non determine. Par 

exemple, si I'on positionne cette valeur a 250 entites, c'est ce dernier nombre qui est pris en compte. Si I'on avait 

choisi un maximum de 7 500 et que le nombre effectif d'entites retournees est de 6 500, c'est cette derniere valeur 

qui aurait ete utilisee par I'annuaire d'IBM. 

Si la valeur maximale autorisee par une implementation d'annuaire est depassee, I'attribut truncated de I'objet 

business List renvoye par la fonction est positionne a la valeur true. Cette situation peut etre verifiee via 

I'utilisation de la methode getTruncatedO appliquee a cet objet business List. 

Ces differences de comportement entre les implementations d'annuaires publics de Microsoft et d'IBM sont 

interessantes. En effet, la specification UDDI ne prevoit pas explicitement de limites associees aux volumes de 

donnees renvoyes par les requetes emises. Ces limites sont laissees a I'appreciation des operateurs des annuaires 

(Operator Site Policy). II s'agit la, typiquement, d'informations qui ont trait a la qualite du service propose (voir 

chapitre 3 : « La qualite de service »). Plus particulierement, ces donnees relevent du domaine des specifications 

operationnelles du service offert. Dans le cas present, ces seuils ont ete identifies par experimentation, mais ils 

peuvent etre egalement publies dans la documentation du service. Cependant, ces informations, que I'on peut 

considerer comme des metadonnees d'utilisation du service, pourraient etre accessibles de maniere programmatique, 

via une extension WSDL de la description du service (caracteristiques de I'instance de service). 



Rechercher des entites metier par le nom qualifie (utilisation de la casse) 

Deuxieme exemple d'utilisation : 

import org.uddi4j . cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import org . uddi 4j . uti 1 .*; 

import Java. util .Vector; 

public class UDDIFindBusiness2 { 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

fqv.add(new FindQual ifier(FindQualifier.caseSensitiveMatch) ) ; 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 
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Vector names = new VectorO; 
names. add (new Name( "Ibm" ) ) ; 
BusinessList bl = proxy .find_business( names, 
null, null, null, null, fqs, 0); 



) 



) 



Ce deuxieme exemple montre comment recuperer 1' ensemble des entites metier dont le nom 
commence obligatoirement par Ibm. Ceci altere le comportement par defaut de la fonction qui est 
insensible a la casse en standard. Voici le resultat renvoye : 

no business(es) found 

Si Ton remplace la valeur de F argument Ibm par IBM, on retrouve le meme resultat que celui obtenu 
dans le premier exemple. 

Rechercher des entites metier par le nom qualifie (epellation exacte) 

Troisieme exemple d' utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 
import org.uddi4j .data type. Name; 
import org. uddi4j .response.*; 
import org.uddi4j . transport. Transport Factory ; 
import org . uddi 4j . uti 1 .*; 
import Java. util .Vector; 

public class UDDIFindBusiness3 { 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

fqv.addtnew FindQual if ier( FindQual if ier.exactNameMatch) ) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 
fqs.setFindQual ifierVector(fqv) ; 

Vector names = new VectorO; 
names. add(new Name( "IBM" ) ) ; 
BusinessList bl = proxy .find_business(names, 
null, null, null, null, fqs, 0); 



) 



) 



Ce troisieme exemple illustre comment recuperer 1' ensemble des entites metier dont le nom est 
exactement IBM. Ceci altere le comportement par defaut de la fonction qui verifie la correspondance 
sur la partie gauche des entrees de l'annuaire comme nous Favons vu dans le premier exemple. Voici 
le resultat renvoye : 



no business(es) found 
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Si Ton remplace la valeur de l'argument IBM par IBM WSTK Tutori al , on obtient le resultat qui suit : 

II business(es) found 
IBM WSTK Tutorial 
fdfdbba0-a7d3-lld5-a30a-002035229c64 

Si Ton remplace la valeur de l'argument IBM WSTK Tutorial parlbm WSTK Tutorial, on obtient egalement 
le meme resultat que ci-avant. II est bien entendu possible de combiner les qualificateurs de recherche 
comme le montre l'exemple suivant. 

Rechercher des entites metier par le nom qualifie 
(epellation exacte et utilisation de la casse) 

Quatrieme exemple d' utilisation : 

import org.uddi4j . cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import org . uddi 4j . uti 1 . *; 

import Java. util .Vector; 

public class UDDIFindBusiness4 { 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

fqv.add(new FindQual ifier( FindQual ifier.exactNameMatch) ) ; 

fqv. add (new FindQual ifier(FindQualifier.caseSensitiveMatch) ) ; 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

Vector names = new VectorO; 
names. add(new NameC'IBM WSTK Tutorial")); 
BusinessList bl = proxy .find_business(names, 
null, null, null, null, fqs, 0); 

} 

} 

Dans ce quatrieme exemple, les qualificateurs de recherche exactNameMatch et caseSensitiveMatch 
sont combines arm de montrer comment recuperer l'ensemble des entites metier dont le nom est 
exactement IBM WSTK Tutorial avec une casse strictement equivalente. Voici le resultat renvoye : 

1 business(es) found 

IBM WSTK Tutorial 

fdfdbba0-a7d3-lld5-a30a-002035229c64 

Si Ton remplace la valeur de l'argument IBM WSTK Tutorial par Ibm WSTK Tutorial, on obtient le 
resultat qui suit : 

no business(es) found 

Pour classer la liste d' entites metier renvoyees par cette fonction, il est possible d'utiliser d'autres 
qualificateurs. 
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Rechercher des entites metier par le nom qualifie (liste triee sur le nom) 

Cinquieme exemple d' utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .data type. Name; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. TransportFactory; 

import org.uddi4j.util .*; 

import Java .util .Vector ; 

public class UDDIFindBusiness5 { 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

fqv.addtnew FindQual if ier( FindQual ifier. sortByNameDesc) ) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 
fqs.setFindQual ifierVector(fqv) ; 

Vector names = new VectorO; 
names. add(new Name( "IBM" ) ) ; 
BusinessList bl = proxy .find_business(names, 
null, null, null, null, fqs, 0); 



) 



) 



Ce cinquieme exemple montre Futilisation des qualificateurs de recherche sortByNameAsc et sortBy- 
NameDesc et leur influence sur l'ordre de restitution des entites metier renvoyees dans la liste. Cet 
exemple met en ceuvre le qualificateur sortByNameDesc. Voici le resultat produit : 

5 business(es) found 

IBM WSTK Tutorial 
fdfdbba0-a7d3-lld5-a30a-002035229c64 

IBM Web Service Demonstrations 
a0ca53e0-cc07-lld6-9d4f-000629dc0a53 

IBM VisualAge Smalltalk 
ee7fede0-3f07-lld5-98bf-002035229c64 

IBM Learning Services Japan Co., Ltd. 
756f61b0-a360-lld6-8eba-000629dc0a53 

IBM Corporation 
d2033110-3aaf-lld5-80dc-002035229c64 

Si Ton remplace le qualificateur sortByNameDesc par le qualificateur sortByNameAsc, on obtient bien 
entendu une liste inverse. 

Pour classer la liste d' entites metier renvoyees par cette fonction, il est egalement possible d'utiliser 
des qualificateurs qui reposent sur la date de la derniere mise a jour des entites metier renvoyees par 
la liste. Ces qualificateurs sont sortByDateAsc et sortByDateDesc. 

En cas d' utilisation combinee, l'ordre de precedence de ces qualificateurs est secondaire par rapport 
aux qualificateurs sortByNameAsc et sortByNameDesc. Dans ce cas, les entites metier seront triees par 
date, ascendante ou descendante, a l'interieur du tri sur le nom. 
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L'ordre ascendant chronologique presente en debut de liste les entites metier dont les dates de la derniere 
mise a jour sont les plus anciennes. Cet ordre est celui qui est utilise par defaut par cette fonction. 

Rechercher des entites metier par le nom qualifie (liste triee sur la date) 

Sixieme exemple d' utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import org . uddi 4j . uti 1 . *; 

import Java. util .Vector; 

public class UDDIFindBusiness6 { 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

fqv.add(new FindQual ifier( FindQual ifier.sortByDateDesc) ) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

Vector names = new VectorO; 
names. add(new NameC'IBM") ) ; 
BusinessList bl = proxy .find_business(names, 
null, null, null, null, fqs, 0); 

} 
} 

Ce sixieme exemple illustre la mise en oeuvre des qualificateurs sortByDateAsc et sortByDateDesc et 
leur influence sur l'ordre de restitution des entites metier renvoyees dans la liste. Cet exemple met 
en oeuvre le qualificateur sortByDateDesc. L'utilisation de ce programme, a ce moment precis, 
renvoie le resultat suivant : 

5 business(es) found 

IBM Web Service Demonstrations 
a0ca53e0-cc07-lld6-9d4f-000629dc0a53 

IBM Learning Services Japan Co., Ltd. 
756f61b0-a360-lld6-8eba-000629dc0a53 

IBM WSTK Tutorial 
fdfdbba0-a7d3-lld5-a30a-002035229c64 

IBM VisualAge Smalltalk 
ee7fede0-3f07-lld5-98bf-002035229c64 

IBM Corporation 
d2033110-3aaf-lld5-80dc-002035229c64 

Ce resultat s'interprete de la maniere suivante : l'entite metier IBM WSTK Tutorial a ete modifiee la 
derniere fois apres l'entite metier IBM VisualAge Smalltalk qui elle-meme a fait l'objet de modifications 
pour la derniere fois apres l'entite IBM Corporation (de la date la plus recente a la plus ancienne). 
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Si Ton remplace le qualificateur sortByDateAsc par le qualificateur sortByDateDesc, on obtient bien 
entendu une liste strictement inverse a celle qui a ete recuperee via la precedente requete. 



Resume de I'ordre des precedences 

Utilisation des qualificateurs exactNameMatch et caseSensitiveMatch : combinaison possible et pas d'ordre 

de precedence entre eux. 

Utilisation des qualificateurs sortByNameAsc et sortByNameDesc : qualificateurs exclusifs et pas d'ordre de 

precedence entre eux. 

Utilisation des qualificateurs sortByDateAsc et sortByDateDesc : qualificateurs exclusifs et pas d'ordre de 

precedence entre eux. 



Comparaisons alphabetiques 

L'utilisation des qualificateurs exactNameMatch, sortByNameAsc et sortByNameDesc fait appel a un ordre de tri 
binaire, insensible a la casse sauf si le qualificateur caseSensi ti veMatch est utilise dans la requete. 



L'utilisation du nom de l'entite metier en tant que critere de recherche n'est pas la seule possibilite 
offerte par FAPI de recherche. En effet, il est egalement possible de rechercher des entites metier a 
partir de valeurs de localisateurs ou reperes (locators) issues des taxonomies standards de classification 
(NAICS, UNSPSC, GEO). 

Rechercher des entites metier par I'index NAICS (liste triee sur le nom) 

Septieme exemple d'utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org. uddi 4 j . response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java. util .Vector; 

public class UDDIFindBusiness7 ( 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr - new KeyedReferencet "Data Processing Services", "51421"); 
kr.setTModelKey("uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"); 

cbv.addElement(kr) ; 

CategoryBag cb = new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier. sortByNameDesc) ; 

fqv.addCfq) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, null, cb, null, fqs, 0); 
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Ce septieme exemple presente Futilisation du localisateur 51421 de la taxonomie NAICS (North 
American Industry Classification System), combinee avec la mise en ceuvre du qualificateur de 
recherche sortByNameDesc. Cet exemple presente, a ce moment precis, la liste des entites metier enre- 
gistrees dans la categorie Data Processing Services de cette taxonomie, triee par ordre alphabetique 
descendant. Voici le resultat renvoye : 

29 business(es) found 

WebCubic, Inc 
602b89d0-4bdd-lld6-9b35-000c0e00acdd 

Arete Systems 
f56c7a97-0c4e-4304-916f-2ffef22936ad 

L'utilisation d'une combinaison de localisateurs est aussi possible. Le prochain exemple met en ceuvre 
un localisateur 51421 (Data Processing Services) de la taxonomie NAICS associe au localisateur 
514191 (On-line Information Services) de cette meme taxonomie. 

Rechercher des entites metier par I'index NAICS 
(index combines et liste triee sur le nom) 

Huitieme exemple d' utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import org . uddi 4j . uti 1 . *; 

import Java. util .Vector; 

public class UDDIFindBusiness8 { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr = new KeyedReferencet "Data Processing Services", "51421"); 

kr.setTModelKey("uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"); 

cbv.addElement(kr) ; 

kr = new KeyedReferencet "On-Line Information Services", "514191"); 

kr.setTModelKey("uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"); 

cbv.addElement(kr) ; 

CategoryBag cb = new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier. sortByNameDesc) ; 

fqv.add(fq) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, null, cb, null, fqs, 0); 

} 

) 

Ce huitieme exemple montre une utilisation du localisateur 51421 de la taxonomie NAICS, associe au 
localisateur 514191 et combine avec la mise en ceuvre du qualificateur de recherche sortByNameDesc. 
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La liste des entites metier restituee passe de 29 a 7 entites metier seulement : la composition des deux 
localisateurs revient a realiser un « et » logique. Voici le resultat renvoye apres execution de ce 
programme : 

7 business(es) found 

Oakley Internet Ltd 
Cb26aeef-c5b9-4512-a747-828a7380462c 

Christopher Labs inc. 
b57b4625-afdf-4d4c-9dcb-47957405c8ec 

Si Ton ajoute le qualificateur orAl 1 Keys a cette requete, la liste d'entites restituees passe a 98 unites. 
Ce qualificateur transforme le « et » logique par defaut d'un ensemble CategoryBag ou Tmodel Bag en 
« ou » logique. 

Si Ton ajoute le qualificateur combi neCategoryBags a cette requete, la liste d'entites restituees passe a 
9 unites. L'usage de ce qualificateur ajoute les deux entites ci-apres aux sept obtenues initialement : 

Advertor 
dl0713d0-e75f-45b5-80be-aafl6143a74b 

1 PC Network Inc. Polycom Video and Audio Conferencing 
820fff8d-443c-487e-a71c-6b03905f4e42 

La presence du qualificateur combi neCategoryBags indique au serveur UDDI que la recherche doit 
combiner les localisateurs de l'entite metier et ceux des services metier qu'elle contient ou reference. 
Les deux entites ci-avant ne portent pas directement les deux localisateurs NAICS utilises, mais 
offrent un service metier reference par ces localisateurs. 

Si Ton ajoute le qualificateur servi ceSubset a cette requete, la liste d'entites restituees passe a 4 unites. 
L'usage de ce qualificateur ajoute les deux entites precedentes a deux des sept obtenues initialement : 

4 business(es) found 

1MB Enterprises 
128ee500-8437-lld5-a3da-002035229c64 

e-Merge Interactive 
15fe61f0-fbl7-lld5-bca4-002035229c64 



Advertor 
d!0713d0-e75f-45b5-80be- 



iaf!6143a74b 



1 PC Network Inc. Polycom Video and Audio Conferencing 
820fff8d-443c-487e-a71c-6b03905f4e42 

Ceci s'explique par la presence du qualificateur servi ceSubset, lequel indique au serveur UDDI que 
la recherche doit eliminer les localisateurs de l'entite metier et porter uniquement sur ceux des services 
metier qu'elle contient ou reference. Les quatre entites ci-avant ne portent pas directement les deux 
localisateurs NAICS utilises, mais offrent au moins un service metier reference par ces localisateurs. 

La taxonomie NAICS n'est pas la seule taxonomie qui peut etre utilisee pour rechercher un sous- 
ensemble des entites metier de l'annuaire. La taxonomie UNSPSC (Universal Standard Products and 
Services Codes), plutot orientee vers une classification des produits, peut egalement etre mise en 
ceuvre en standard. 
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Rechercher des entites metier par I'index UNSPSC (liste triee sur le nom) 

Neuvieme exemple d' utilisation : 

mport org.uddi4j .cl i ent. UDDI Proxy ; 

mport org. uddi4j .response.*; 

mport org.uddi4j .transport .Transport Factory ; 

mport org . uddi 4j . uti 1 . *; 

mport Java. util .Vector; 

public class UDDIFindBusiness9 { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 
KeyedReference kr = new KeyedReference( 

"Document management software", "43161801"); 
kr.setTModelKey("uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384"); 

cbv.addElement(kr) ; 

CategoryBag cb = new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.add(fq) ; 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 



BusinessList bl = proxy .find_business(nul 1 , null, null, cb, null, fqs, 0); 



} 

) 



Ce neuvieme exemple illustre comment utiliser le localisateur 43161801 (Document management 
software), combine avec la mise en ceuvre du qualificateur de recherche sortByNameDesc. Voici le 
resultat renvoye a F execution de ce programme : 

7 business(es) found 

XYZFind 
C5038el0-3aaf-lld5-80dc-002035229c64 

Anthony Macauley Associates 
4a33fee5-e5d8-4dc5-a9b8-lbe3f7f47al5 

Les localisateurs de differentes taxonomies peuvent etre mixes dans une meme requete. Cette precedente 
requete peut par exemple etre raffinee en combinant la mise en ceuvre du localisateur 43161801 de la 
taxonomie UNSPSC avec le localisateur 51421 de la taxonomie NAICS. 

Rechercher des entites metier par les index NAICS et UNSPSC combines 
(liste triee sur le nom) 

Dixieme exemple d' utilisation : 

I import org. uddi 4 j .cl i ent. UDDI Proxy ; 
import org. uddi 4j .response.*; 
import org. uddi 4 j .transport .Transport Factory ; 
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import org.uddi4j.util .*; 
import Java. util .Vector; 

public class UDDIFindBusinesslO { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr - new KeyedReferencet "Data Processing Services", "51421"); 

kr.setTModelKey("uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"); 

cbv.addElement(kr) ; 

kr = new KeyedReferencet "Document management software", "43161801"); 

kr.setTModelKey("uuid:DB77450D-9FA8-45D4-A7BC-04411D14E384"); 

cbv.addElement(kr) ; 

CategoryBag cb = new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.addCfq) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, null, cb, null, fqs, 0); 

} 

) 



Ce dixieme exemple illustre comment utiliser le localisateur 43161801 (Document management 
software) de la taxonomie UNSPSC, associe au localisateur 51421 (Data Processing Services) de la 
taxonomie NAICS, le tout combine avec la mise en ceuvre du qualificateur de recherche sortByName- 
Desc. Voici le resultat renvoye a l'execution de ce programme : 

2 business(es) found 

1MB Enterprises 
128ee500-8437-lld5-a3da-002035229c64 

IBM Corporation 
d2033110-3aaf-lld5-80dc-002035229c64 

Un dernier exemple montre le mixage de differentes taxonomies dans une meme requete. La specifica- 
tion prevoit une derniere taxonomie centree sur la geographie : la taxonomie GEO. II est possible, par 
exemple, de recuperer les entites metier associees au localisateur 51421 de la taxonomie NAICS et 
basees aux Etats-Unis. Ce dernier critere de recherche est associe au localisateur US de la taxonomie GEO. 

Rechercher des entites metier par les index NAICS et GEO combines 
(liste triee sur le nom) 

Onzieme exemple d'utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org. uddi 4j .response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java .util .Vector; 
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public class UDDIFindBusinessll { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr = new KeyedReferencet "Data Processing Services", "51421"); 

kr.setTModelKey("uuid:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"); 

cbv.addElement(kr) ; 

kr = new KeyedReferencet "United States", "US"); 

kr.setTModelKey("uuid:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88"); 

cbv.addElement(kr) ; 

CategoryBag cb - new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.add(fq); 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, null, cb, null, fqs, 0); 

} 

} 

Ce onzieme exemple illustre comment utiliser le localisateur 51421 (Data Processing Services) de la 
taxonomie NAICS, associe au localisateur US (United States) de la taxonomie GEO, le tout combine 
avec la mise en ceuvre du qualificateur de recherche sortByNameAsc. Voici le resultat renvoye a 
1' execution de ce programme : 

2 business(es) found 

1MB Enterprises 
128ee500-8437-lld5-a3da-002035229c64 

Data Recovery Services 
Ie3cec48-5c39-4b64-84b4-9d3af3edale4 

Rechercher des entites metier par I'index D-U-N-S (liste triee sur le nom) 

II existe une autre serie de taxonomies qui sont egalement prises en charge par la specification UDDI 
et permettent de retrouver une entreprise a partir d'un identifiant unique. La version 2.0 d'UDDI integre 
le support de la taxonomie Dun & Bradstreet D-U-N-S Number (Data Universal Numbering System). 

Cette taxonomie repose sur un numero d'identification d'une entreprise ou d'un etablissement unique 
au niveau mondial. Ce numero a neuf chiffres est exclusif et est attribue gratuitement par Dun & 
Bradstreet (voir http://www.dnb.com) a toute entreprise presente dans sa base de donnees. Cette base de 
donnees recense les societes meres, filiales, sieges sociaux et branches de plus de soixante-six 
millions d'entreprises dans le monde entier. Ce systeme d'identification des entreprises, cree en 1962, 
est devenu une reference mondiale et est deja reconnu comme un standard dans le domaine des 
echanges de donnees electroniques EDI (Electronic Data Interchange). II est notamment reconnu par la 
Commission Europeenne, FISO (International Organization for Standardization) et l'ONU (Organisation 
des Nations unies). 
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Douzieme exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org. uddi4j .response.*; 

import org.uddi'4j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java . util .Vector; 

public class UDDIFindBusinessl2 { 

public static void main(String[] args) throws Exception { 

Vector ibv = new VectorO; 

KeyedReference kr - new KeyedReference( "" , "789388907"); 

kr.setTModelKey("uuid:8609C81E-EElF-4D5A-B202-3EB13AD01823"); 

ibv.addElement(kr) ; 

kr = new KeyedReference( "" , "007932671"); 

kr.setTModelKey("uuid:8609C81E-EElF-4D5A-B202-3EB13AD01823"); 

ibv.addElement(kr) ; 

IdentifierBag ib = new IdentifierBag( ) ; 

ib.setKeyedReferenceVector(ibv) ; 

Vector fqv = new VectorO; 

FindQualifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.add(fq) ; 

FindQual if iers fqs = new FindQual if iers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, ib, null, null, fqs, 0); 

} 
} 

Ce douzieme exemple illustre comment utiliser l'identificateur D-U-N-S 789388907 (qui correspond a 
la societe Optical Image Technology, Inc.) de la taxonomie Dun & Bradstreet D-U-N-S Number, 
associe a l'identificateur D-U-N-S 007932671 (identificateur de la societe Able Consulting, Inc.) de la 
meme taxonomie, le tout combine avec la mise en ceuvre du qualificateur de recherche sortByNameDesc. 
Voici le resultat renvoye a 1' execution de ce programme : 

2 business(es) found 

Optical Image Technology, Inc. 
03daeldf-c88f-4ee9-b6c8-739004f57e9f 

Able Consulting, Inc. 
ae5b04e6-bbd7-4881-ab75-3e562c4a85f4 

La liste restituee par ce programme montre done que cette combinaison d'identificateurs revient a 
realiser un « ou » logique. 

La version 2.0 de la specification UDDI integre egalement le support de la taxonomie Thomas Register. 

Rechercher des entites metier qui implemented un service type particulier 
(liste triee sur le nom) 

II est possible d'effectuer une recherche dont Fobjectif consiste a retrouver la liste des entites metier 
qui implementent un ou plusieurs services types. Ce type de requete peut etre realise via Futilisation 
des classes TModel Bag et TModel Key. 
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Treizieme exemple d' utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import org . uddi 4j . uti 1 .*; 

import Java. util .Vector; 

public class UDDIFindBusinessl3 { 

public static void main(String[] args) throws Exception { 

Vector tbv = new VectorO; 

TModelKey tk = new TModel Key( "uuid:64c756dl-3374-4e00-ae83-eel2e38fae63") ; 

tbv.addElement(tk) ; 

tk = new TModel Key("uuid:4cd7e4bc-648b-426d-9936-443eaac8ae23") ; 

tbv.addElement(tk) ; 

TModel Bag tb = new TModel BagO; 

tb.setTModelKeyVector(tbv); 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.add(fq) ; 

FindQual ifiers fqs = new FindQualifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

BusinessList bl = proxy .find_business(nul 1 , null, null, null, tb, fqs, 0); 

} 
} 

Ce dernier exemple montre comment recuperer la liste des entites metier qui implementent le service 
type uddi-org:publication (dont la cle est uuid:64c756dl-3374-4e00-ae83-eel2e38fae63) et le service 
type uddi-org:inquiry (dont la cle est uuid:4cd7e4bc-648b-426d-9936-443eaac8ae23). L'operation 
realisee ici est en fait un « et » logique. Cette requete est combinee avec la mise en ceuvre du qualifi- 
cateur de recherche sortByNameDesc. Voici le resultat renvoye a F execution de ce programme : 

4 business(es) found 

Systinet Inc. 
651d547a-edcc-495f-b758-36af04fl82cf 

SAP AG 
a694dcd4-9d88-lld6-91b6-0003479a7335 

Microsoft UDDI Business Registry Node 
6c068bd0-21f8-40f0-9742-94e60e68d690 

IBM Corporation 
d2033110-3aaf-lld5-80dc-002035229c64 

La liste restituee par ce programme presente en fait la liste des societes qui offrent une implementation 
de deux des API du noyau de la specification UDDI 1.0, c'est-a-dire de FAPI de recherche (Inquiry API) 
et de FAPI de publication (Publishing API). IBM et Microsoft prennent en charge F implementation 
de reference depuis la version 1.0 de UDDI, et SAP depuis la version 2.0 (compatibilite ascendante) : 
ces trois societes font partie des operateurs de Fannuaire public UDDI (voir chapitre suivant). Systinet 
(ex-Idoox) propose egalement son produit WASP UDDI qui constitue une implementation d'annuaire 
UDDI prive, accessible en evaluation sur Internet. 
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La fonction find_relatedBusinesses 

La fonction f 1 nd_rel atedBusi nesses permet de rechercher une oil plusieurs entites metier associees a 
une entite metier donnee. 

Cette fonction renvoie un message rel atedBusi nesses List. Eneas de recherche infructueuse, laliste 
renvoyee est vide. Dans le cas contraire, le message rel atedBusi nesses List retourne est constitute de 
structures de donnees de type rel atedBusinessInfo incluses dans une collection rel atedBusi ness Infos. 

Syntaxe du message find_related Businesses 

La syntaxe de ce message est la suivante : 

<find_relatedBusinesses [maxRows="nn"] generic="2.0" 

xmlns="urn:uddi-org:api_v2"> 

[<findQualifiers/>] 

<businessKey/> 

[<keyedReference/>] 
</find_rel atedBusi nesses> 

Lattribut business Key specifie la cle de 1' entite metier particuliere sur laquelle porte la recherche 
d'entites metier associees. 

L element keyedRef erence est optionnel et permet de preciser le type d' association entre entites metier 
a considerer pour produire la liste resultante. Les types d'association permis sont references par une 
taxonomie particuliere uddi-org:relationships (cle : uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03). 
Les associations autorisees sont : 

• parent-child : 1' entite metier dont la cle est fournie doit etre parente de celles qui seront renvoyees 
dans la liste ; 

• peer-peer : l'entite metier dont la cle est fournie ne presente pas de lien de parente avec celles qui 
seront renvoyees dans la liste ; 

• identity : l'entite metier dont la cle est fournie represente la meme entite que celles qui seront 
renvoyees dans la liste. 

Le schema de la structure de donnees rel atedBusinessInfo, contenue dans le message rel atedBusi - 
nesses List, se presente ainsi : 

<element name="rel atedBusinessInfo" type="uddi :rel atedBusinessInfo" /> 
<complexType name=" rel atedBusi ness Info"> 
<sequence> 

<element ref="uddi :businessKey" /> 
<element ref="uddi :name" maxOccurs="unbounded" /> 

<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 
<element ref="uddi :sharedRel ationships" max0ccurs="2" /> 
</sequence> 
</complexType> 
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Rechercher des entites metier associees a une entite metier donnee 

Exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j . datatype. tmodel .TModel ; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import org.uddi4j .util . Keyed Reference; 

import Java. util .Vector; 

public class UDDIFindRel atedBusinessesl { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr = new KeyedReferencet "peer-peer" , "peer-peer"); 

kr.setTModel Key (TModel. RE LATIONSHIPS_TMODEL_KEY); 

Rel atedBusinessesList rbl = proxy .find_relatedBusinesses( 
"ee7a7a30-f67c-lld6-b618-000629dc0a53", kr, null, 0); 

RelatedBusinessInfos rbis = rbl .getRelatedBusinessInfos( ) ; 
if (rbis.sizeO == 0) ( 

System. out. printlnt "no related business(es) found"); 

System. exit(0) ; 
} 

System. out. println(rbis. size( )+" related business(es) found\n"); 
Vector rbiv = rbis.getRelatedBusinessInfoVector( ) ; 
for (int i =0; i < rbiv.sizeO; i++) { 

Rel atedBusinessInfo rbi = (Rel atedBusinessInfo)rbiv.elementAt(i ) ; 

System. out . printlnt rbi . getNameStringt )) ; 

System. out. printlnt rbi .get Business Key ( ) ) ; 

System. out .printlnt "\n" ) ; 

SharedRelationships srs = rbi .getSharedRelationshipst ) ; 

System. out. printlnC'di rection : "+srs .getDirectiont ) ) ; 

Vector krv = srs.getKeyedReferenceVectort ) ; 

System. out. printlntkrv. sizet )+" shared rel ationship(s) found\n"); 

for (int j = 0; j < krv.sizeO; j++) { 
kr = (KeyedReference)krv.elementAt( j) ; 
System. out. printlnt "name : "+kr.getKeyName( ) ) ; 



System. out. printlnt "val ue : "+kr.getKeyValue( ) ) ; 
System. out. printlnt "\n" ) ; 



} 



I 



) 



Cet exemple illustre comment recuperer l'ensemble des entites metier associees a Fentite metier WS-I 
organization (dont la cle est ee7a7a30-f67c-lld6-b618-000629dc0a53), dont le type d'association 
correspond a une relation de type peer-peer. 

Ce programme retourne le resultat suivant : 

I 4 related business(es) found 
Bowstreet WS-I 
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e94f7ad0-0705-lld7-97cf-000629dc0a53 

direction : fromKey 

1 shared relationship(s) found 

name : peer-peer 
value : peer-peer 

Oracle Sample Web services 

46a3f630-d695-lld6-a6b8-000629dc0a53 

direction : fromKey 

1 shared relationship(s) found 

name : peer-peer 
value : peer-peer 

Ce resultat s'interprete de la maniere suivante : l'entite metier WS-I organization est la source 
(voir di recti on : fromKey) de quatre relations de type peer-peer (dont seules deux d'entre elles sont 
representees ici) avec notamment les entites metier Bowstreet WS-I et Oracle Sample Web services. 

La meme requete, realisee avec une KeyedReference qui reference une association de type parent- 
child, renverra le resultat suivant : 

no related business(es) found 

La fonction find_service 

La fonction find_service permet de rechercher un ou plusieurs elements de type businessServiceen 
fonction de differents criteres. 

Cette fonction renvoie un message serviceList. En cas de recherche infructueuse par rapport aux 
criteres de recherche utilises, la liste renvoyee est vide. Dans le cas contraire, le message servi ceLi st 
retourne est constitue de structures de donnees de type servi celnfo incluses dans une collection 

servicelnfos. 

Syntaxe du message find_service 

La syntaxe de ce message est la suivante : 

<find_service [businessKey="uu7'c/_/cey"] [maxRows="nn"] generic="2.0" 

xmlns="urn:uddi -org:api_v2"> 

[<findQualifiers/>] 

[<name/> [<name/>]...] 

[<categoryBag/>] 

[<tModelBag/>] 
</find_service> 

Lattribut businessKey est optionnel et specifie la cle de l'entite metier particuliere sur laquelle porte 
la recherche de services metier. Seuls les services metier foumis par cette entite metier sont susceptibles 
de figurer dans la liste resultante. Dans le cas contraire, la recherche porte sur toutes les entites metier de 
l'annuaire. 

L'element name precise une collection de noms complets ou partiels de services metier a rechercher : 
la liste resultante est constitute de tous les services dont le nom correspond a cette collection de 



Decouvrir un service avec UDDI 

Chapitre 1 1 

valeurs. La correspondance est evaluee en commencant par la gauche pour les noms partiels. Les 
noms peuvent etre qualifies via l'attribut xml : 1 ang. 

Le schema de la structure de donnees servi celnfo, contenue dans le message servi ceLi st, se presente 
ainsi : 

<element name="serviceInfo" type="uddi :serviceInfo" /> 
<complexType name="serviceInfo"> 

<sequence> 

<element ref="uddi :name" minOccurs="0" maxOccurs="unbounded" /> 

</sequence> 

attribute name="serviceKey" type="uddi :serviceKey" use="required" /> 

<attribute name="businessKey" type="uddi :businessKey" use="requi red" /> 
</complexType> 

Les exemples qui suivent montrent comment utiliser ces differents elements du message et, eventuel- 
lement, comment les combiner entre eux pour rechercher des services metier. Afin de trouver des 
exemples supplementaires de mise en oeuvre des arguments f i ndQual i f i ers, categoryBag et tModel Bag, 
le lecteur pourra se referer a la section precedente, « La fonction find_business », dans laquelle 
d'autres utilisations possibles de ces elements sont decrites. 

Rechercher des services metier 

Premier exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import Java. util .Vector; 

public class UDDIFindServicel { 

public static void main(String[] args) throws Exception { 

Vector names = new VectorO; 
names. add(new Name( "%")); 
ServiceList si - proxy. find_service( 

"D2033110-3AAF-11D5-80DC-002035229C64", names, null, null, null, 0); 

Servicelnfos sis = si .getServicelnfost ) ; 
if (sis.sizeO == 0) { 

System. out. printlnC'no service(s) found"); 

System. exit(0) ; 
} 

System. out. println(sis. size( )+" service(s) found\n"); 
Vector siv = sis.getServicelnfoVectort ) ; 
for (int i = 0; i < siv.sizeO; i++) { 

Servicelnfo si = (Servicelnfo)siv.elementAt(i ) ; 

System. out. printlnt si .getNameString( ) ) ; 

System. out. printlnt si .getServiceKey( ) ) ; 

Sy stem. out . printlnt "\n" ) ; 
} 
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Ce premier exemple illustre comment recuperer l'ensemble des services metier proposes par l'entite 
metier IBM Corporation (dont la cle est D2033110-3AAF-11D5-80DC-002035229C64). II s'agit ici d'une 
recherche standard, sans filtrage sur le nom des services recuperes, ni utilisation de qualificateurs de 
recherche. 

Ce programme retourne le resultat suivant : 

10 service(s) found 

Buy from IBM 
894b5100-3aaf-lld5-80dc-002035229c64 

UDDI Business Registry inquiry 
892a3470-3aaf-lld5-80dc-002035229c64 

Rechercher des services metier par le nom qualifie (liste triee sur le nom) 

Second exemple d' utilisation : 

import org. uddi 4 j .cl i ent. UDDI Proxy ; 

import org. uddi 4 j .datatype. Name; 

import org. uddi 4 j . response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java. util .Vector; 

public class UDDIFindService2 ( 

public static void main(String[] args) throws Exception { 

Vector fqv = new VectorO; 

FindQual ifier fq = new FindQual ifier(FindQualifier.sortByNameDesc) ; 

fqv.addElementCfq) ; 

FindQual ifiers fqs = new FindQual ifiers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

Vector names = new VectorO; 
names. addtnew Name( "%registr%" ) ) ; 
ServiceList si = proxy .find_service( 

"D2033110-3AAF-11D5-80DC-002035229C64", names, null, null, fqs, 0); 

} 
} 

Ce second exemple presente la maniere de recuperer l'ensemble des services metier proposes par 

l'entite metier IBM Corporation (cle D2033110-3AAF-11D5-80DC-002035229C64), dont le nom du service 

comprend le mot registr. Cet ensemble est renvoye trie par ordre alphabetique decroissant via la 

mise en ceuvre du qualificateur de recherche sortByNameDesc. 

Ce programme retourne le resultat suivant : 

3 service(s) found 

UDDI Business Registry inquiry 
892a3470-3aaf-lld5-80dc-002035229c64 

IBM Personal Systems reseller registration 
89307600-3aaf-lld5-80dc-002035229c64 
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L'utilisation des elements findQualifiers et name comme arguments de cette requete a permis de 
reduire la liste de dix services metier renvoyee a Tissue de F execution du premier exemple a une liste 
de seulement trois services metier. 

La fonction find_tModel 

La fonction f 1 nd_tModel permet de rechercher un ou plusieurs elements de type tModel en fonction de 
differents criteres. 

Cette fonction renvoie un message tModel List. En cas de recherche infructueuse par rapport aux 
criteres de recherche utilises, la liste renvoyee est vide. Dans le cas contraire, le message tModel Li st 
retourne est constitue de structures de donnees de type tModel Info incluses dans une collection 

tModel Infos. 

Syntaxe du message f ind_tModel 

La syntaxe de ce message est la suivante : 

<find_tModel [maxRows="nn"] generic="2.0" xmlns="urn:uddi -org:api_v2"> 

[<findQualifiers/>] 

[<name/>] 

[<identif ierBag/>] 

[<categoryBag/>] 
</find_tModel> 

L element name precise un nom complet ou partiel de services types a rechercher : la liste resultante 
est constitute de tous les services types dont le nom correspond a cette valeur. La correspondance est 
evaluee en commencant par la gauche pour les noms partiels. 

Le schema de la structure de donnees tModel Info, contenue dans le message tModel Li st, se presente ainsi : 

<element name="tModel Info" type="uddi :tModel Info" /> 
<complexType name="tModel Info"> 

<sequence> 

<element ref="uddi :name" /> 

</sequence> 

<attribute name="tModel Key" type="uddi :tModel Key" use="requi red" /> 
</complexType> 

Les exemples qui suivent montrent comment utiliser ces differents elements du message et si necessaire 
comment les combiner entre eux pour rechercher des services types. Afin de trouver des exemples 
supplementaires de mise en ceuvre des arguments findQualifiers, identifierBag et categoryBag, le 
lecteur pouira se referer a la section dediee a la fonction f 1 nd_busi ness dans laquelle d'autres utilisations 
possibles de ces differents elements sont decrites. 

Rechercher des services type par le nom 

Premier exemple d'utilisation : 

I import org.uddi4j .cl i ent. UDDI Proxy ; 
import org. uddi4j .response.*; 
import org.uddi4j .transport .Transport Factory ; 
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import Java. util .Vector; 
public class UDDIFindTModel 1 { 

public static void main(String[] args) throws Exception { 

TModelList tl = proxy. find_tModel ( "uddi-org%" , null, null, null, ); 

TModel Infos tis = tl .getTModel Infos( ) ; 
if (tis.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 

System. exit(0) ; 
} 

System. out. printlnttis. size( )+" tmodel(s) found\n"); 
Vector tiv = tis .getTModel InfoVector( ) ; 
for (int i =0; i < tiv.sizeO; i++) { 

TModel Info ti = (TModel Info)tiv.elementAt(i ) ; 

System. out. println(ti .getNameStringC )) ; 

System. out. println(ti .getTModel Key( ) ) ; 

Sy stem. out. println("\n") ; 
} 
} 
} 

Cet exemple montre comment recuperer l'ensemble des services types dont le nom commence par 
uddi -org. Voici le resultat renvoye : 

19 tmodel (s) found 






uddi -org:fax 
Uuid:la2b00be-6e2c-42f5-875b-56f32686e0e7 

uddi -org: types 
uuid:clacf26d-9672-4404-9d70-39b756e62ab4 

La liste restituee par ce programme comporte l'ensemble des services types decrits dans la specification 
UDDI, dont la responsabilite incombe a F organisation UDDI. Cette liste ne comprend pas les services 
types ntis-gov:naics:1997, unspsc-org:unspsc:3-l, unspsc-org:unspsc, dnb-com:D-U-N-S et thomasregister- 
com:supplierID qui sont egalement references par la specification UDDI, mais dont la responsabilite 
de gestion appartient aux entites metier qui les controlent. 

Rechercher des services type par le nom qualifie (liste triee sur le nom) 

Second exemple d' utilisation : 

import org. uddi 4 j .cl i ent. UDDI Proxy ; 

import org. uddi 4 j . response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import org.uddi4j.util .*; 

import Java. util .Vector; 

public class UDDIFindTModel 2 { 

public static void main(String[] args) throws Exception { 

Vector cbv = new VectorO; 

KeyedReference kr = new KeyedReferencet "types" , "identifier"); 

kr.setTModelKey("uuid:clacf26d-9672-4404-9d70-39b756e62ab4"); 
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cbv.addElement(kr) ; 

CategoryBag cb = new CategoryBag( ) ; 

cb.setKeyedReferenceVector(cbv) ; 

Vector fqv = new VectorO; 

FindQual ifier fq; 

fq = new FindQualifier(FindQualifier.sortByNameDesc) ; 

fqv.add(fq); 

FindQual ifiers fqs = new Fi ndQual i f i ers( ) ; 

fqs. set FindQual ifierVector(fqv) ; 

TModelList tl = proxy. find_tModel (nul 1 , cb, null, fqs, ); 

} 

} 

Ce second exemple permet d'extraire la liste des services types qui sont enregistres dans la categorie 
des taxonomies d'identificateurs de recherche. II met en ceuvre le qualificateur sortByNameDesc. 

L' utilisation de ce programme produit le resultat suivant : 

39 tmodel (s) found 

WSUI 
uuid:5288efd0-5640-lld6-beff-000c0e00acdd 

Acer TWP Technology CO., ??????????? (Training) 
uuid:2c6fc390-0663-lld7-97cf-000629dc0a53 

Cette requete restitue notamment les services types qui figurent en standard sous forme de taxonomies 
dans la specification UDDI et qui permettent d'effectuer des interrogations de Fannuaire par identifi- 
cateurs de recherche, c'est-a-dire, les taxonomies : 

• dnb-com:D-U-N-S (cle uuid:8609c81e-eelf-4d5a-b202-3ebl3ad01823) ; 

• thomasregister-com:supplierID (cle uuid:blblbaf5-2329-43e6-ael3-ba8e97195039). 

Dans cette liste, on peut egalement noter la presence de la taxonomie ntis-gov:sic: 1987 qui a ete ajoutee 
aux taxonomies standards sur le site Web UDDI de Microsoft et qui introduit la possibilite d'utiliser 
une classification des activites par secteurs industriels d'origine nord-americaine : la Standard Industrial 
Classification (SIC) (voir adresse du site de reference : http://www.census.gov/epcd/www/sic.html). Cette 
classification a depuis ete remplacee par la classification North American Industry Classification 
System (NAICS) etablie conjointement par les Etats-Unis, le Mexique et le Canada. 

Une autre taxonomie presente dans ce resultat de requete est egalement interessante pour les entites 
metier localisees aux Etats-Unis : il s'agit de la taxonomie sec-gov:cik-key qui correspond a la 
classification Electronic Data Gathering, Analysis and Retrieval System (EDGAR) utilisees par la 
U.S. Securities and Exchange Commission (SEC), l'equivalent de la Commission des operations de 
bourse en France (COB), pour les echanges de documents et declarations auxquels sont astreintes les 
entreprises americaines qui sont cotees en bourse (voir adresse du site de reference : http://www.sec.gov). 
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Le mot-cle « identifier » 

Le mot-cle « identifier » utilise dans cette requite provient de la taxonomie uddi-org:types, et il taut savoir qu'il est 
possible d'effectuer d'autres types de recherches. Le document de reference qui decrit I'API de programmation 
(voir http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdfpour la version 2.0 d'UDDI) precise dans 
I'annexe I « Utility tModels and Conventions » les autres valeurs possibles. Cette annexe precise d'une maniere 
plus generale les conventions retenues pour I'enregistrement de services types dans I'annuaire et les services 
utilitaires standards qui sont fournis a cette fin. 



La fonction get_bindingDetail 

La fonction get_bi ndi ngDetai 1 permet de recuperer les informations qui detaillent un modele de liaison. 
Ces informations pourront ensuite etre utilisees pour invoquer I'API metier referencee par cette liaison. 

Cette fonction renvoie un message bi ndi ngDetai 1, constitue de structures de donnees de type 
bindingTemplate. Si plusieurs cles de modeles de liaison sont passees en parametre, le resultat sera 
renvoye dans un ordre de cles identique. 

Syntaxe du message get_bindingDetail 

La syntaxe de ce message est la suivante : 

I <get_bi ndi ngDetai 1 generic="2.0" xmlns="urn:uddi-org:api_v2"> 
<bindingKey/> [<bindingKey/> ...] 
</get_bi ndi ngDetai 1 > 

Lelement bi ndi ngKey fournit une ou plusieurs cles d'instances de modeles de liaison. 

Le schema de la structure de donnees de type bi ndi ngTempl ate est presente dans la section dediee a la 
fonctionfind_binding. 

Les exemples qui suivent montrent comment utiliser cet element du message pour recuperer un ou 
plusieurs modeles de liaison. 

Rechercher le detail d'un modele de liaison identifie 

Premier exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

i mport org . uddi 4 j .datatype . bi ndi ng . Bi ndi ngTempl ate ; 

import org.uddi4j . response. Bi ndi ngDetai 1 ; 

import org. uddi 4 j .transport. Transport Factory; 

import Java .util .Vector ; 

public class UDDIGetBi ndi ngDetai 1 1 { 

public static void main(String[] args) throws Exception { 

Bi ndi ngDetai 1 bd = proxy .get_bindingDetail ( 
"6BCC8130-3AAF-11D5-80DC-002035229C64" ) ; 

Vector bdv = bd.getBindingTemplateVector( ) ; 
if (bdv.sizeO == 0) { 

System. out. printlnCno binding(s) found"); 
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System.exit(O) ; 
} 

System. out .println(bdv.size( )+" binding(s) found\n"); 
for (int i = 0; i < bdv.sizeO; i++) { 

BindingTemplate bt = (BindingTempl ate)bdv.elementAt(i ) ; 

System. out. println(bt.getDefaul tDescriptionStringt )) ; 

System. out. println(bt.getBindingKey( ) ) ; 

System. out. print ln("\n") ; 



Ce premier exemple presente la recuperation des details d'un modele de liaison qui constitue Fune 
des implementations de F API de publication UDDI via le protocole HTTP, implementation fournie par 
le service metier Publish to the UDDI Business Registry (cle 6BCC8130-3AAF-11D5-80DC-002035229C64), 
pris en charge par l'entite metier IBM Corporation. La cle du modele de liaison que Ton souhaite 
obtenir doit etre obligatoirement precisee. Voici le resultat renvoye : 

II binding(s) found 
Publish to UDDI Business Registry (web) 
6BCC8130-3AAF-11D5-80DC-002035229C64 

Le modele de liaison intitule Publish to UDDI Business Registry (Web) et restitue par ce programme 
est Fun des quatre modeles de liaison exposes par ce service metier. A partir de cet objet, il est possible 
de recuperer tous les details de F implementation et surtout FURL du point d'acces Internet qui 
permet d'invoquer ce service. 

Rechercher le detail de plusieurs modeles de liaison identifies 

II est possible de recuperer plusieurs modeles de liaison par un seul acces a Fannuaire UDDI. 
L exemple qui suit montre comment proceder a cette operation. 

Second exemple d' utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. binding. BindingTempl ate; 

import org.uddi4j . response. BindingDetail ; 

import org.uddi4j . transport. Transport Factory ; 

import Java. util .Vector; 

public class UDDIGetBi ndi ngDetai 1 2 { 

public static void main(String[] args) throws Exception { 

Vector bkv = new VectorO; 

bkv.addElement("6BCC8130-3AAF-llD5-80DC-002035229C64"); 

bkv.addElement("8AF9BD40-4584-llD5-BD6C-002035229C64"); 



BindingDetail bd = proxy .getJn'ndingDetail (bkv) ; 



) 



Cet exemple illustre la recuperation simultanee des details de plusieurs modeles de liaison qui 
constituent autant d' implementations de FAPI de publication UDDI via le protocole HTTP, 
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implementations fournies par le service metier Publish to the UDDI Business Registry pris en 
charge par Fentite metier IBM Corporation. Voici le resultat renvoye : 

2 binding(s) found 

Publish to UDDI Business Registry (web) 
6BCC8130-3AAF-11D5-80DC-002035229C64 
Publish to UDDI Test Registry (web) 
8AF9BD40-4584-11D5-BD6C-002035229C64 

Les modeles de liaison intitules Publish to UDDI Business Registry (web) et Publish to UDDI Test 
Registry (web) et restitues par ce programme constituent deux des quatre modeles de liaison exposes 
par ce service metier. En pratique, ils correspondent tous deux aux points d'acces aux interfaces Web 
des annuaires de test et de production UDDI d'IBM. Les deux modeles de liaison ont ete restitues 
dans Fordre exact des cles passees a la fonction. 

La fonction get_businessDetail 

La fonction get„busi nessDetai 1 permet de recuperer les informations qui detaillent une ou plusieurs 
entites metier. 

Cette fonction renvoie un message bus i nessDetai 1 , constitue de structures de donnees de type business 
Entity. Si plusieurs cles d'entites metier sont passees en parametre, le resultat sera renvoye dans un 
ordre de cles identique. 

Syntaxe du message get_businessDetail 

La syntaxe de ce message est la suivante : 

I <get_busi nessDetai 1 gene ric=" 2.0" xmlns="urn:uddi-org:api_v2"> 
<businessKey/> [<businessKey/> ...] 
</get_busi nessDetai 1 > 

L'element businessKey fournit une ou plusieurs cles d'instances d'entites metier. 

Le schema de la structure de donnees businessEntity, contenue dans le message businessDetail, se 
presente ainsi : 

<element name="businessEntity" type="uddi :businessEntity" /> 
<complexType name="businessEntity"> 
<sequence> 

<element ref="uddi :discoveryURLs" minOccurs="0" /> 

<element ref="uddi :name" maxOccurs="unbounded" /> 

<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 

<element ref="uddi :contacts" minOccurs="0" /> 

<element ref="uddi :businessServices" minOccurs="0" /> 

<element ref="uddi :identifierBag" minOccurs="0" /> 

<element ref="uddi :categoryBag" minOccurs="0" /> 
</sequence> 

<attribute name="businessKey" type="uddi :businessKey" use="requi red" /> 
<attribute name="operator" type="string" use="optional " /> 
<attribute name="authorizedName" type="string" use="optional " /> 
</complexType> 
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Les exemples qui suivent montrent comment utiliser cet element du message pour recuperer une ou 
plusieurs entites metier en une seule interrogation de l'annuaire. 

Rechercher le detail d'une entite metier identifiee 

Premier exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. business. Business Entity; 

import org.uddi4j .response. Business Detail ; 

import org.uddi4j . transport. Transport Factory ; 

import Java. util .Vector; 

public class UDDIGetBusinessDetail 1 { 

public static void main(String[] args) throws Exception { 

BusinessDetail bd = proxy. get_businessDetail ( 
"D2033110-3AAF-11D5-80DC-002035229C64" ) ; 

Vector bev = bd.getBusinessEntityVectort ) ; 
if (bev.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

System. out .println(bev.size( )+" business(es) found\n"); 
for (int i = 0; i < bev.sizeO; i++) { 

BusinessEntity be = (BusinessEntity)bev.elementAt(i ) ; 

System. out. printl n( be. getDefaul tNameSt ring ( ) ) ; 

System. out. printlnt be. getBusinessKey( ) ) ; 

System.out.println("\n") ; 



Ce premier exemple illustre la maniere de recuperer les details descriptifs d'une entite metier specifiee 
par sa cle, en Foccurrence il s'agit de l'entite metier IBM Corporation. La cle de l'entite metier que 
Ton cherche a recuperer doit etre obligatoirement precisee (cle de l'entite metier IBM Corporation : 
D2033110-3AAF-11D5-80DC-002035229C64). Voici le resultat renvoye : 

II business(es) found 
IBM Corporation 
D2033110-3AAF-11D5-80DC-002035229C64 

Rechercher le detail de plusieurs entites metier identifies 

II est possible de recuperer plusieurs entites metier par un seul acces a l'annuaire UDDI, F exemple 
suivant illustre cette possibilite. 

Second exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. business. Business Entity; 

import org.uddi4j .response. BusinessDetail ; 

import org.uddi4j .transport .Transport Factory ; 
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import Java. util .Vector; 

public class UDDIGetBusinessDetail 2 { 

public static void main(String[] args) throws Exception { 

Vector bkv = new VectorO; 

bkv.addElement("D2033110-3AAF-HD5-80DC-002035229C64"); 

bkv.addElement("0076B468-EB27-42E5-AC09-9955CFF462A3"); 

BusinessDetail bd = proxy. get_businessDetail (bkv) ; 

} 
} 

Ce second exemple presente la recuperation simultanee des details de plusieurs entites metier. Voici 
le resultat renvoye : 

2 business(es) found 

IBM Corporation 
D2033110-3AAF-11D5-80DC-002035229C64 

Microsoft Corporation 
0076B468-EB27-42E5-AC09-9955CFF462A3 

Les deux entites metier sont restituees dans l'ordre positionnel des cles passees en parametre de la 
fonction. 

La fonction get_businessDetailExt 

La fonction get_business Detail Ext permet de recuperer les informations etendues qui detaillent une 
ou plusieurs entites metier. 

Cette fonction renvoie un message businessDetailExt, constitue de structures de donnees de type 
businessEntityExt. Si plusieurs cles d'entites metier sont passees en parametre, le resultat sera 
renvoye dans un ordre de cles identique. 

Les informations retournees par cette fonction sont strictement identiques a celles qui sont restituees 
par la fonction get_businessDetail precedente. Seules quelques informations complementaires sont 
renvoyees lorsque l'entite metier provient d'un operateur d'annuaire externe via le mecanisme de 
replication entre implementations d'annuaires. 

Syntaxe du message get_businessDetailExt 

La syntaxe de ce message est la suivante : 

I<get_businessDetailExt gene ric=" 2.0" xmlns="urn:uddi-org:api_v2"> 
<businessKey/> [<businessKey/> ...] 
</get_businessDetail Ext> 

L'element businessKey fournit une ou plusieurs cles d'instances d'entites metier. 

Le schema de la structure de donnees businessEntityExt, contenue dans le message business Detail Ext, 
se presente ainsi : 

|<element name="businessEntityExt" type="uddi :businessEntityExt" /> 
<complexType name= "business Entity Ext "> 
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<sequence> 

<element ref="uddi :businessEntity" /> 
<any namespace="#other" processContents="strict" 
minOccurs="0" maxOccurs="unbounded" /> 
</sequence> 
</complexType> 

Les exemples qui suivent montrent comment utiliser cet element du message pour recuperer une ou 
plusieurs entites metier en un seul acces a l'annuaire. 

Rechercher le detail etendu d'une entite metier identif iee 

Premier exemple d'utilisation : 

import org.uddi4j , cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. business. Business Entity; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import Java. util .Vector; 

public class UDDIGetBusinessDetail Extl { 

public static void main(String[] args) throws Exception { 

BusinessDetail Ext bde = proxy .get_businessDetailExt( 
"D2033110-3AAF-11D5-80DC-002035229C64" ) ; 

Vector beev = bde.getBusinessEntityExtVector( ) ; 
if (beev.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

System. out. println(beev. size( )+" business(es) found\n"); 
for (int i = 0; i < beev.sizeO; i++) { 

BusinessEntityExt bee = (BusinessEntityExt)beev.elementAt(i ) ; 

BusinessEntity be = bee.getBusinessEntityt ) ; 

System. out. printlnt be. getDefaul tNameString( ) ) ; 

System. out. printl n( be. getBusinessKey( ) ) ; 

System.out.println("\n" ) ; 
} 
} 
} 

Ce premier exemple illustre la maniere de recuperer les details descriptifs etendus d'une entite metier 
specifiee par sa cle, il s'agit en l'occurrence de l'entite metier IBM Corporation. La cle de l'entite 
metier que Ton cherche a recuperer doit etre obligatoirement precisee (cle de l'entite metier IBM 
Corporation : D2033110-3AAF-11D5-80DC-002035229C64). Voici leresultatrenvoye : 

1 business(es) found 

IBM Corporation 
D2033110-3AAF-11D5-80DC-002035229C64 
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Rechercher le detail etendu de plusieurs entites metier identifies 

II est possible de recuperer les informations etendues de plusieurs entites metier par un seul acces a 
l'annuaire UDDI, comme le montre l'exemple suivant. 

Second exemple d' utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. business. Business Entity; 

import org.uddi4j . response. BusinessDetail Ext; 

import org.uddi4j .response. Business Entity Ext; 

import org.uddi4j .transport. Transport Factory; 

import Java .util .Vector ; 

public class UDDIGetBusinessDetail Ext2 ( 

public static void main(String[] args) throws Exception { 

Vector bkv = new VectorO; 

bkv.addElement("D2033110-3AAF-HD5-80DC-002035229C64"); 

bkv.addElement("0076B468-EB27-42E5-AC09-9955CFF462A3"); 

BusinessDetail Ext bde = proxy. get_businessDetail Ext(bkv) ; 



Ce second exemple met en ceuvre la recuperation simultanee des details etendus de plusieurs entites 
metier. Dans cet exemple, on recherche les informations etendues des entites metier IBM Corporation 
et Microsoft Corporation. Les cles des entites metier que Ton cherche a recuperer doivent etre obli- 
gatoirement precisees (cle de Fentite IBM Corporation : D2033110-3AAF-11D5-80DC-002035229C64 ; 
cle de Fentite Microsoft Corporation : 0076B468-EB27-42E5-AC09-9955CFF462A3). Voici le resultat renvoye : 

2 business(es) found 

IBM Corporation 
D2033110-3AAF-11D5-80DC-002035229C64 

Microsoft Corporation 
0076B468-EB27-42E5-AC09-9955CFF462A3 

Les deux entites metier sont restituees dans Fordre positionnel des cles passees en parametre de la fonction. 

La fonction get_serviceDetail 

La fonction get^serviceDetail permet de recuperer les informations qui detaillent un ou plusieurs 
services metier. 

Cette fonction renvoie un message servi ceDetai 1 , constitue de structures de donnees de type busi ness 
Servi ce. Si plusieurs cles de services metier sont passees en parametre, le resultat sera renvoye dans 
un ordre de cles identique. 

Syntaxe du message get_serviceDetail 

La syntaxe de ce message est la suivante : 

<get_serviceDetail gener7'c="2.0" xmlns="urn:uddi-org:api_v2" > 



Decouvrir un service avec UDDI 

Chapitre 1 1 

I<serviceKey/> [<serviceKey/> ...] 
</get_servi ceDetai 1 > 

L' element servi ceKey fournit une ou plusieurs cles d'instances de services metier. 

Le schema de la structure de donnees businessService, contenue dans le message servi ceDetai 1, se 
presente ainsi : 

<element name="businessService" type="uddi :businessService" /> 
<complexType name="businessService"> 
<sequence> 

<element ref="uddi :name" minOccurs="0" maxOccurs="unbounded" /> 
<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 
<element ref="uddi :bindingTemplates" minOccurs="0" /> 
<element ref="uddi :categoryBag" minOccurs="0" /> 
</sequence> 

<attribute name="serviceKey" type="uddi :serviceKey" use="required" /> 
<attribute name="businessKey" type="uddi :businessKey" use="optional " /> 
</complexType> 

Les exemples qui suivent montrent comment utiliser cet element du message pour recuperer un ou 
plusieurs services metier en une seule interrogation de l'annuaire. 

Rechercher le detail d'un service metier identifies 

Premier exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org.uddi4j .datatype. service. BusinessService; 

import org.uddi4j .response. Servi ceDetai 1 ; 

import org.uddi4j . transport. Transport Factory ; 

import Java. util .Vector; 

public class UDDIGetServiceDetail 1 { 

public static void main(String[] args) throws Exception { 

Servi ceDetai 1 sd = proxy .get_servi ceDetai 1 ( 
"892d41b0-3aaf -Ild5-80dc-002035229c64" ) ; 

Vector bsv = sd.getBusinessServiceVector( ) ; 
if (bsv.sizeO == 0) { 

System. out. printlnC'no service(s) found"); 

System. exit(0) ; 
} 

System. out. println(bsv. sizeC )+" service(s) found\n"); 
for (int i = 0; i < bsv.sizeO; i++) { 

BusinessService bs = (BusinessService)bsv.elementAt(i ) ; 

System. out. printlntbs.getDefaul tNameString( ) ) ; 

System. out. println(bs.getServiceKey( ) ) ; 

System.out.println("\n" ) ; 
} 
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Ce premier exemple illustre la maniere de recuperer les details descriptifs d'un service metier specifie par 
sa cle, en Foccurrence le service metier Publish to the UDDI Business Registry foumi par l'enrite metier 
IBM Corporation. La cle du service metier que Ton cherche a recuperer doit etre obligatoirement precisee 
(cle du service metier Publish to the UDDI Business Registry : 892d41b0-3aaf-lld5-80dc-002035229c64). 

L'utilisation de ce programme produit le resultat suivant : 
1 service(s) found 

Publish to the UDDI Business Registry 
892d41b0-3aaf-lld5-80dc-002035229c64 

Rechercher le detail de plusieurs services metier identifies 

II est egalement possible de recuperer plusieurs services metier par un seul acces a Fannuaire UDDI, 
comme le montre l'exemple suivant. 

Second exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org.uddi4j .datatype.service.BusinessService; 

import org.uddi4j . response. ServiceDetail ; 

import org.uddi4j . transport. TransportFactory; 

import Java .util .Vector; 

public class UDDIGetServiceDetail2 { 

public static void main(String[] args) throws Exception { 

Vector skv = new VectorO; 

skv.addElement("892a3470-3aaf-lld5-80dc-002035229c64") 
skv.addElement("892d41b0-3aaf-lld5-80dc-002035229c64") 
skv .addEl ementt "bd22c024-5f93-43d0-b09e-eeal88f 19768" ) 

ServiceDetail sd = proxy. get_serviceDetail (skv) ; 



Ce second exemple presente la recuperation simultanee des details de plusieurs services metier. II 
s'agit ici d'obtenir les details des services metier UDDI Business Registry inquiry (cle 892a3470-3aaf- 
Ild5-80dc-002035229c64) et Publish to the UDDI Business Registry (cle 892d41b0-3aaf-lld5-80dc- 
002035229c64) fournis par Fentite metier IBM Corporation, ainsi que les details du service metier 
UDDI Services (cle bd22c024-5f 93-43d0-b09e-eeal88f 19768) expose par Fentite metier Microsoft UDDI 
Business Registry Node. Voici le resultat renvoye : 

3 service(s) found 

UDDI Business Registry inquiry 
892a3470-3aaf-lld5-80dc-002035229c64 

Publish to the UDDI Business Registry 
892d41b0-3aaf-lld5-80dc-002035229c64 

UDDI Services 
bd22c024-5f93-43d0-b09e-eeal88f 19768 
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Les trois services metier sont restitues dans l'ordre positionnel des cles passees en parametres de la 
fonction. 

La fonction get_tModelDetail 

La fonction get_tModel Detail permet de recuperer les informations qui detaillent un ou plusieurs 
services types. 

Cette fonction renvoie un message tModel Deta i 1 , constitue de structures de donnees de type tModel . 
Si plusieurs cles de services types sont passees en parametre, le resultat sera renvoye dans un ordre de 
cles identique. 

Syntaxe du message get_tModel Detail 

La syntaxe de ce message est la suivante : 

I <get_tModel Detail generic="2.Q" xmlns="urn:uddi -org:api_v2" > 
<tModelKey/> [<tModel Key/> ...] 
</get_tModelDetail> 

L element tModel Key fournit une ou plusieurs cles d'instances de services types. 

Le schema de la structure de donnees tModel , contenue dans le message tModel Detai 1 , se presente ainsi : 

<element name="tModel " type="uddi :tModel " /> 
<complexType name="tModel "> 
<sequence> 

<element ref="uddi :name" /> 

<element ref="uddi :description" minOccurs="0" maxOccurs="unbounded" /> 
<element ref="uddi :overviewDoc" minOccurs="0" /> 
<element ref="uddi :identifierBag" minOccurs="0" /> 
<element ref="uddi :categoryBag" minOccurs="0" /> 
</sequence> 

<attribute name="tModel Key" type="uddi :tModel Key" use="requi red" /> 
<attribute name="operator" type="string" use="optional " /> 
<attribute name="authorizedName" type="string" use="optional " /> 
</complexType> 

Les exemples qui suivent montrent comment utiliser cet element du message pour recuperer un ou 
plusieurs services types en une seule interrogation de l'annuaire. 

Rechercher le detail d'un service type identifies 

Premier exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 
import org.uddi4j . datatype. tmodel .TModel ; 
import org.uddi4j .response. TModel Detail ; 
import org.uddi4j . transport. Transport Factory ; 
import Java. util .Vector; 

public class UDDIGetTModel Detai 1 1 { 

public static void main(String[] args) throws Exception { 
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TModel Detail td = proxy .get_tModel Detail ( 

"UUID:4CD7E4BC-648B-426D-9936-443EAAC8AE23" ) ; 

Vector tv = td.getTModel Vectort ) ; 
if (tv.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 

System. exit(0) ; 
} 

System. out. printlnttv. size( )+" tmodel(s) found\n"); 
for (int i =0; i < tv.sizeO; i++) { 

TModel t = (TModel )tv.elementAt(i); 

Sys tern. out. println(t.getNameString( ) ) ; 

Sys tern. out. printlnU.getTModel Key( ) ) ; 

Sy stem. out. println("\n") ; 
} 



) 



) 



Ce premier exemple illustre la maniere de recuperer les details descriptifs d'un service type specifie 
par sa cle, en Foccurrence le service type uddi -org : i nqui ry. La cle du service type que Ton cherche 
a recuperer doit etre obligatoirement precisee (cle du service type uddi-org:inquiry : UUID:4CD7E4BC- 
648B-426D-9936-443EAAC8AE23). Voici le resultat renvoye : 

II tmodel (s) found 
uddi -orgn'nqui ry 
UUID:4CD7E4BC-648B-426D-9936-443EAAC8AE23 

Rechercher le detail de plusieurs services types identifies 

II est possible de recuperer plusieurs services types par un seul acces a Fannuaire UDDI. L' exemple 
suivant met en ceuvre cette possibilite. 

Second exemple d' utilisation : 

import org. uddi 4 j .cl i ent. UDDI Proxy ; 

import org. uddi 4 j .datatype. tmodel .TModel ; 

import org. uddi 4 j . response. TModel Detail ; 

import org.uddi4j . transport. TransportFactory; 

import Java. util .Vector; 

public class UDDIGetTModel Detail 2 { 

public static void main(String[] args) throws Exception { 

Vector tkv = new VectorO; 

tkv.addElement("UUID:4CD7E4BC-648B-426D-9936-443EAAC8AE23"); 

tkv.addElement("UUID:64C756Dl-3374-4E00-AE83-EE12E38FAE63"); 



TModelDetail td = proxy .get_tModel Detail (tkv) ; 



) 



) 



Ce second exemple presente la recuperation simultanee des details de plusieurs services types. En 
Foccurrence, il s'agit de recuperer les details des services types uddi-org:inquiry (cle UUID:4CD7E4BC-648B- 
426D-9936-443EAAC8AE23)et uddi -org : publication (cle UUID:64C756Dl-3374-4E00-AE83-EE12E38FAE63) qui 
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correspondent aux fonctions des API de recherche et de publication UDDI qui sont mises en ceuvre a 
travers ces cas d' utilisation. Voici le resultat renvoye : 

2 tmodel (s) found 

uddi -org: inquiry 
UUID:4CD7E4BC-648B-426D-9936-443EAAC8AE23 

uddi -org :publ i cation 
UUID:64C756Dl-3374-4E00-AE83-EE12E38FAE63 

Les deux services types sont restitues dans Fordre positionnel des cles passees en parametre de la 
fonction. 
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Le chapitre 11a illustre les possibilites de decouverte de services introduites par les annuaires UDDI. 
Nous savons maintenant comment rechercher des entites metier, les relations eventuelles qui existent 
entre elles, les services metier qu'elles offrent, les services types qu'elles implementent via leur offre 
et les modeles de liaison qui permettent d'acceder a ces services metier et de les consommer. 

Mais comment toutes ces informations pratiques sont-elles publiees dans ces annuaires ? Quelles 
sont les fonctions disponibles ? Quelles sont les implementations d' annuaires UDDI qui existent 
aujourd'hui ? Comment y acceder ? Quelles sont les evolutions prevues ? Autant de questions 
auxquelles ce chapitre va tenter de repondre. 

La publication et la replication 

Un annuaire UDDI peut etre public ou prive (voir la section « Les implementations d' annuaires 
UDDI » en fin de chapitre). De maniere standard, la specification prevoit qu'un annuaire sera distribue 
sur plusieurs sites operateurs repliques entre eux. La replication n'est pas obligatoire, notamment dans 
un cadre prive, mais est fortement recommandee pour des raisons evidentes de disponibilite. Cette 
fonctionnalite est bien stir mise en ceuvre par 1' annuaire public UDDI, dont les implementations des 
operateurs (IBM, Microsoft, NTT Communications et SAP) se repliquent entre elles. 

Cette caracteristique des annuaires UDDI introduit certaines consequences en matiere de publication 
d' informations. En effet, lorsque Fadministrateur UDDI d'une organisation (entreprise, administration, 
association. . .) souhaite publier des informations dans un annuaire UDDI, il doit d'abord choisir l'un 
des operateurs de 1' annuaire et ouvrir un compte aupres de l'operateur retenu (public ou prive). 
Ensuite, il pourra interagir avec F annuaire au moyen d'une interface Web dediee ou par programme 
via FURL du service Web d'acces aux fonctions de publication du site de l'operateur choisi. Les 
informations qu'il publiera seront alors automatiquement repliquees vers les autres implementations 
de F annuaire UDDI. 



Technologies des services Web 

Deuxieme Partie 

S'il souhaite mettre a jour les informations initialement enregistrees, il ne pourra le faire qu'aupres 
du site de l'annuaire initialement utilise, quel que soit le canal d'acces choisi (interface Web ou 
service Web). Toute tentative de modification, a partir d'une autre implementation de l'annuaire 
(geree par un autre operateur), sera refusee et un message d'erreur sera retourne. Cela vient du fait 
que, contrairement au contenu de l'annuaire, les comptes d'acces aux differents sites d'un annuaire 
ne sont pas eux-memes repliques. 

De meme, si l'administrateur UDDI d'une organisation ouvre deux comptes d'acces sur deux sites 
operateurs d'un meme annuaire et enregistre les memes informations sur chacun des deux sites, tout 
se passe comme s'il avait cree des entites metier differentes, des services metier differents, etc. Meme 
si tous les attributs de ces objets sont identiques, les cles generees seront differentes et il lui sera 
toujours impossible de modifier les informations qui ont ete sauvegardees dans une implementation 
de l'annuaire via un acces a F autre implementation de cet annuaire. 

Le principe de fonctionnement peut etre resume ainsi : unicite du point de mise a jour des informations 
et replication partout de ces informations. Ce principe est appele single-master primary-copy replication 
par les specialistes des bases de donnees reparties. 

La publication d'un service 

L' API de publication (Publishing API) est presentee en detail dans le document de reference UDDI 
Version 2.04 API Specification (voir http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf). 

Cette API comporte seize fonctions, dont onze d'entre elles etaient deja disponibles en version 1.0. 
Ces fonctions peuvent etre organisees en quatre groupes homogenes. 

Le premier groupe comporte les fonctions d'authentification : 

• la fonction get_authToken demande un jeton d'authentification a l'operateur de l'annuaire, ce 
jeton est requis pour toutes les autres fonctions de 1' API de publication ; 

• la fonction di scard_authToken demande l'invalidation du jeton prealablement fourni par la fonction 

get_authToken ; 

• la fonction get_regi steredlnfo demande un resume de 1' information geree par un administrateur 
UDDI (liste des entites metier et des services types administres par cette personne). 

Le deuxieme groupe rassemble les fonctions de creation et de mise a jour des structures de donnees 
UDDI: 

• la fonction save_business enregistre une nouvelle entite metier ou met a jour une entite metier 
existante ; 

• la fonction save_service enregistre un nouveau service metier ou met a jour un service metier 
specifique a l'interieur d'une entite metier ; 

• la fonction save_binding enregistre une nouvelle liaison ou met a jour une liaison existante 
specifique a l'interieur d'un service metier ; 

• la fonction save_tModel enregistre un nouveau service type ou met a jour un service type existant. 
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Les fonctions de suppression des structures de donnees UDDI constituent le troisieme groupe : 

• la fonction del ete_busi ness supprime des informations enregistrees pour une entite metier ; 

• la fonction del ete_servi ce supprime un service specifique a l'interieur d'une entite metier ; 

• la fonction del ete_bi ndi ng supprime une liaison specifique a l'interieur d'un service metier ; 

• la fonction del ete_tModel supprime un service type specifique. Cette suppression est seulement 
logique car le service type peut etre reference par ailleurs. 

La version 2.0 de l'API a ajoute cinq nouvelles fonctions de gestion des assertions (voir la remarque 
« Relations entre entites metier » ci-apres) qui represented le quatrieme groupe : 

• la fonction get_publisherAssertions recherche des assertions relationnelles associees au compte 
de l'utilisateur ; 

• la fonction add_publ i sherAsserti ons ajoute des assertions relationnelles a l'ensemble des assertions 
existantes, associees au compte de l'utilisateur ; 

• la fonction set_publ i sherAsserti ons affecte des assertions relationnelles, associees au compte de 
l'utilisateur ; 

• la fonction del ete_publi sherAsserti ons supprime des assertions relationnelles a un ensemble 
d' assertions existantes, associees au compte de l'utilisateur ; 

• la fonction get_asserti onStatus Report demande un rapport sur la situation des assertions relationnelles 
associees au compte de l'utilisateur. 



Relations entre entites metier 

La capacite de decrire des relations entre entites metier est nouvelle et a ete introduite dans la version 2.0 d'UDDI. 
Cela est realise au moyen d'assertions emises par les administrateurs UDDI (publishers) en charge des entites 
concernees. Une fois validees par les administrateurs respectifs, les relations decrites deviennent visibles et sont 
accessibles par la fonction find_relatedBusinesses presentee dans le chapitre precedent. Cette double validation 
permet d'eviter que de fausses assertions emises unilateralement par un administrateur ne deviennent publiques. 
Par exemple, si I'administrateur UDDI de I'entite metier EM, souhaite exprimer I'existence d'une relation de type 
parent-chi 1 d avec I'entite metier EM 2 (EM 2 est filiale de EM,), il doit publier I'assertion qui stipule cette relation. 
Pour autant, cette relation ne devient pas automatiquement visible. Pour qu'elle le devienne, il est indispensable 
que I'administrateur UDDI de I'entite metier EM 2 (qui peut etre le meme que celui de I'entite metier EM,, mais pas 
necessairement) publie exactement la meme assertion. Apres verification des assertions par le(s) noeud(s) UDDI 
qui controle(nt) le(s) compte(s) administrateur concerne(s), celles-ci sont validees et la relation ainsi exprimee 
devient visible. En cas de refus de publication par le second administrateur, I'assertion du premier administrateur 
reste virtuelle et demeure invisible aux utilisateurs de I'annuaire UDDI. 



Toutes les fonctions de publication sont securisees via l'utilisation du protocole SSL 3.0. 

Le fonctionnement de chacune des fonctions de cette API est illustre a l'aide d'un ou plusieurs exemples. 
Comme les exemples de l'API de recherche, ces exemples utilisent I'annuaire de production de 
Microsoft (implementation cote serve ur UDDI). En ce qui concerne la partie cliente UDDI, celle-ci 
met egalement en ceuvre le langage Java et plus particulierement F implementation UDDI4J d'IBM. 
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Les fonctions d'authentification 

Les trois fonctions d'authentification prennent en charge la securite des acces en mise a jour des 
informations d'un annuaire. Toutes les fonctions de publication sont mises en ceuvre par des echanges 
securises (SSL) de messages accompagnes du jeton attribue lors de l'authentification. 

La fonction get_authToken 

La fonction get_authToken permet de demander a l'operateur de l'annuaire un jeton d' acces arm de 
pouvoir effectuer des operations de publication. II s'agit d'une fonction optionnelle qui peut ne pas 
etre mise en ceuvre si l'operateur de l'annuaire dispose d'un moyen externe de delivrance de jetons 
d' acces. 

Voici la definition WSDL de 1' operation : 

<operation name="get_authToken"> 

<input message="tns :get_authToken"/> 

<output message="tns:authToken"/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message get_authToken est la suivante : 

I<get_authToken xmlns="urn:uddi-org:api_v2" generic="2.0" 
userID=" String" cred=" Stri ng" /> 

L'attribut userlD contient le login du compte d'acces utilisateur a l'annuaire. 
L'attribut cred contient le mot de passe du compte d'acces utilisateur a l'annuaire. 
La syntaxe du message authToken est la suivante : 

I<authToken xmlns="urn:uddi-org:api_v2" generic="2.0" operator="Str7'ng , "> 
<authInfo>Str7'ng</authInfo> 
</authToken> 

L'element authlnfo contient le jeton utilise comme element d'authentification dans tous les appels 
subsequents aux fonctions de l'API de publication UDDI. 

Demander I'acquisition d'un jeton d'authentification 
Exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org.uddi4j .response. AuthToken; 

import org.uddi4j . transport. TransportFactory ; 

import Java. security .Security ; 

public class UDDIGetAuthTokenl { 

public static void main(String[] args) throws Exception { 

Le code suivant selectionne F implementation du gestionnaire de protocole HTTPS (implementation 
de reference Sun Microsystems) a mettre en ceuvre par l'API de publication, puis active l'implemen- 
tation du protocole de transport a utiliser par la requete (implementation Apache Axis), et cree 
ensuite l'instance de proxy-client UDDI. Enfin, il affecte l'adresse de l'annuaire UDDI a laquelle 
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seront adressees les requetes de recherche et de publication. Cette partie du code est identique dans 
tous les exemples qui suivent : elle sera done omise dans les prochains exemples. 

System. set Property (" Java. protocol .handler.pkgs", 
"com. sun. net. ssl .internal .www.protocol") ; 

Security.addProvider(new com. sun. net. ssl .internal .ssl . Provider ( )) ; 

Sys tern. setPropertyt Transport Factory. PROPERTY_NAME, 
"org. uddi4j. transport. ApacheAxisTransport") ; 

UDDIProxy proxy = new UDDIProxyO; 

proxy.setInquiryURL("http://uddi .microsoft.com/inquire") ; 
proxy. setPubl is hURL("https://uddi .microsoft.com/publish") ; 

Le programme demande un jeton d'authentification pour un utilisateur dont le login est user et le mot 
de passe password : 

AuthToken at = proxy .get_authToken("user" , "password"); 
System. out. printlnCtoken = "+at.getAuth!nfoString( ) ) ; 



Cet exemple montre comment realiser l'acquisition d'un jeton d'authentification aupres du site de 
l'operateur. La communication avec Fannuaire UDDI est realisee via le protocole (SOAP sur) HTTPS. 
Voici le resultat renvoye a l'utilisation de ce programme : 

token = 3JPmhlLhHDl FBrn" Jg8i U4Vrp9JDaKyuOTi hi AbJ*znV*c ! 71 P587G73I9W71 nl 3ci NEcdmtl 

m00TAfzw8Zw5wljg$$;3m05JEgwmGNXDPKc*pA2je92NVTzbj9rKZPRED*R6oFINuSZj8Hd9MtZU26ph 
BnV*rUakpTQNs4DD2uIkGMDaXlKh!7mxx04fyvNA!AvlTAklpdzrxN13k88APLPT91rGjgRb7CLrKsJL 
TqRjw4*gc6mgeyDAqfN8!AWHlj**QuOE$ 

La fonction discard_authToken 

Lafonction discard_authToken permet de demander a l'operateur du site de detruire le jeton d'acces 
a l'annuaire precedemment alloue au demandeur via une fonction get_authToken. 

II s'agit d'un message optionnel qui n'est pas pris en charge si l'operateur du site ne prend pas non plus en 
charge la fonction get_authToken ou s'il ne prend pas en charge la gestion des etats de session utilisateur. 

Une fois cette fonction executee, toute autre invocation ulterieure d'une fonction quelconque de 
l'API de publication associee au meme jeton d'acces est rejetee. 

Voici la definition WSDL de 1' operation : 

<operation name="discard_authToken"> 

<input message="tns:discard_authToken"/> 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message di scard_authToken est la suivante : 

I<discard_authToken xmlns="urn:uddi-org:api_v2" generic="2.0"> 
<authInfo>5tr7'n<7</authInfo> 
</discard_authToken> 
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L'element authlnfo contient le jeton d'authentification a invalider. 

Cette fonction renvoie un message di sposi ti onReport qui fournit simplement le resultat de 1' operation. 
La syntaxe du message en cas de reussite est : 

i<dispositionReport xmlns="urn:uddi-org:api_v2" generic="2.0" operator="String"> 
<result errno="0"/> 
</di sposi tionReport> 

La syntaxe du message en cas d'echec est : 

<di sposi ti onReport xml ns=" urn: uddi -org :api_v2" generic="2.0" 

opera tor=" String" [truncated="true|false"]> 

<result [keyType="/cey Type"] errno=" int"> 

[<errInfo errCode=" St ring"> St ring</err!r\fo>~] 

</result> 
</di sposi tionReport> 

Demander I'annulation d'un jeton d'authentification 
Exemple d' utilisation : 

import org. uddi 4 j .cl i ent.UDDI Proxy ; 

import org. uddi 4j .response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import j a va. security .Security ; 

public class UDDIDiscardAuthTokenl { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. printlnt "token - "+at.getAuthInfoString( )) ; 

DispositionReport dr = proxy .discard_authToken(at.getAuthInfo( )) ; 
System. out. printlnt "\ntoken discarded : "+dr.success( ) ) ; 
} 
} 

Cet exemple montre comment demander I'annulation du jeton d'authentification prealablement 
accorde a l'utilisateur user par le site de l'operateur. Voici le resultat renvoye a 1' utilisation de ce 
programme : 

token = 3SwQivyFlD7LriLAKBVcClVsH3uXHm01eTTE6ZQAGtsT02*leiYo3!U0SkZB9TPiSvgdW*nx 
RJlIMqF5p8M!oSlA$$;3B9rQn6SHa77zOG15cwh6!xUERHMqFQriJ8JcNiSBJ!DXwV8tvPWcHx2uEJa5 
JXYImbV4JAqL!eleerw*uHeGYu8QvflUAgBg!GLTJP0!CFA!M*3xaN35EJwnA*rYYygnGGc*sAfyB70t 
DbrqmI7EZNmt2VrRRqsYjyzofPy4dlYE$ 

token discarded : true 

La fonction get_registeredlnfo 

La fonction get_regi steredlnf o permet de demander une liste abregee des entites metier et des services 
types administres par la personne qui s'authentifie. 
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Voici la definition WSDL de 1' operation : 

<operation name="get_registeredInfo"> 

<input message="tns:get_registeredInfo"/> 

<output message="tns: registered I nfo"/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message get_regi steredlnf o est la suivante : 

I<get_registeredInfo xmlns="urn:uddi -org:api_v2" generic="2.0"> 
<authInfo>5iT7'ng</authInfo> 
</get_registeredInfo> 

L' element authlnfo contient le jeton d'authentification de F administrates. 
La syntaxe du message regi steredlnf o est la suivante : 

<registeredInfo xmlns="urn:uddi-org:api_v2" generic="2.0" operator="S£r7'ng"> 

[<businessInfos/>] 

[<tModelInfos/>) 
</registeredInfo> 

Cette fonction renvoie un message registeredlnfo qui contient des listes d'elements businesslnfo et 
tModel Info. Chacun de ces elements donne des informations detaillees sur les entites metier et les 
services types sous controle exclusif de cet administrateur. 

Demander la liste des informations gerees 
Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import Java. security. Security ; 

import Java. util .Vector; 

public class UDDIGetRegisteredlnfol { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken("user" , "password"); 

Registeredlnfo ri = proxy .get_registeredInfo(at.getAuthInfoString( )) ; 

Businesslnfos bis = ri .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 
} 
el se { 

Production de la liste des entites metier controlees par l'utilisateur user : 

System. out. printlntbis. size( )+" business(es) found\n"); 
Vector biv = bis .getBusinessInfoVectort ) ; 
for (int i =0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAt(i ) ; 



Technologies des services Web 

Deuxieme Partie 



Sys tern. out. printlntbi .getNameString( )) ; 
Sys tern. out. printlntbi . get Business Key ( ) ) ; 
System. out. print! n( "\n") ; 



) 



TModel Infos tis - ri .getTModel Infos( ) ; 
if (tis.sizeO == 0) { 

System. out. println( "no tmodel(s) found"); 
} 
else { 

Production de la liste des services types controles par Futilisateur user 

System. out .println(tis.size( )+" tmodel(s) found\n"); 
Vector tiv = tis. getTModel InfoVector( ) ; 
for (int i = 0; i < tiv.sizeO; 1++) { 

TModel Info ti = (TModel Info)tiv.elementAt(i ) ; 

System. out. printlntti .getNameString( ) ) ; 

System. out. printlntti .getTModel Key( )) ; 

System.out.println("\n") ; 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 
} 
} 

Cet exemple illustre la recuperation des entites metier et des services types controles par la personne 
qui demande un jeton d'authentification aupres du site de Foperateur, a partir des coordonnees de son 
compte utilisateur (user et password). Voici le resultat renvoye a Futilisation de ce programme : 

1 business(es) found 

Services Web & compagnie 
ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

1 tmodel (s) found 

servi cesweb-compagni e-com: i nqui ry 
uuid:lec88662-04b6-4231-a47f-39529db6f22c 

Cette personne dispose ducontroled'uneentite metier dontlenom est Services Web & compagnie (cle 
ba748c9d-73ce-4cd9-85f8-294edddcbbf 0). Elle controle egalement un service type intitule servi cesweb- 
compagni e-com: inquiry (cle uuid:lec88662-04b6-4231-a47f-39529db6f22c). 



Les fonctions de creation et de mise a jour 

Les quatre fonctions de creation et de mise a jour sont utilisees pour creer ou modifier les instances 
des quatre principales structures de donnees gerees par un annuaire UDDI : les entites metier, les 
services metier, les modeles de liaison et les services types. 

La fonction save_business 

La fonction save_busi ness permet de demander a Foperateur du site d'enregistrer ou de modifier une 
ou plusieurs entites metier en une seule operation. 
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Pour enregistrer une nouvelle entite metier, il faut simplement laisser l'attribut de la cle vide. Si la cle 
est fournie, il s'agit d'une modification d'une entite metier existante. 

Voici la definition WSDL de F operation : 

■(operation name="save_business"> 

<input message="tns:save_business"/> 

<output message="tns: business Detail "/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message save__busi ness est la suivante : 

<save_business generic="2.0" xmlns="urn:uddi-org:api_v2"> 

<authInfo>StrfAjg</authInfo> 

<businessEntity/> [<busi ness Entity />...] 
</save_business> 

L' element authlnfo contient le jeton d'authentification. 

Les elements businessEntity represented des entites metier dans un ordre indifferent. 

Cette fonction renvoie un message businessDetail qui reflete le resultat final de l'operation et les 
informations nouvellement enregistrees dans l'annuaire : 

<busi ness Detail gene ric=" 2.0" xmlns="urn:uddi-org:api_v2" 

operator="Str7Ajfi(" [truncated="true|fal se"]> 

<businessEntity/> [<busi ness Entity />...] 
</businessDetail> 

Demander renregistrement d'une entite metier 
Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org.uddi4j .datatype. business. Business Entity; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import Java. security. Security ; 

import Java. util .Vector; 

public class UDDISaveBusinessl { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken("user" , "password"); 

BusinessEntity be = new BusinessEntityt "" , "service Web & compagnie" ) ; 

Vector entities - new VectorO; 
entities.addElement(be) ; 

BusinessDetail bd = proxy .save_business(at.getAuthInfoString( ) , entities); 
System. out. printlnC'new business saved\n"); 



Technologies des services Web 

Deuxieme Partie 



Apres avoir sauvegarde la nouvelle entite, il faut verifier le resultat a Faide de la fonction f i nd_busi ness : 

Vector names = new VectorO; 
names .add (new Name( "service Web & compagnie")) ; 
BusinessList bl = proxy .find_business( 
names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 
} 
el se { 

System. out. println(bis. size( )+" business(es) found\n"); 
Vector biv = bis.getBusinessInfoVectort ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 
System. out. printlntbi .getNameString( ) ) ; 
System. out .pri ntl n(bi .getBusi ness Key C )) ; 
System.out.println("\n") ; 



) 



proxy .di sea rd_authToken( at. getAuth Info ( )] 



Cet exemple illustje la creation d'une nouvelle entite metier, nommee Services Web & compagnie. Ici, 
la cle de F entite metier n'est pas speciflee, ce qui signifle qu'il s'agit d'une creation. Mais elle pouiTait 
l'etre : en effet, il est possible de reaffecter une cle anterieure, deja affectee auparavant a cette entite, 
arm de la modifier ou de la recreer apres suppression. 



Afin de ne pas alourdir cet exemple, de nombreuses structures de donnees dependantes de I'entite metier ne sont 
pas mises en ceuvre ici: Contact, Email, Phone, Address, Description, CategoryBag, etc. Par ailleurs, 
plusieurs taxonomies de categorisation auraient egalement pu etre utilisees dans cet exemple : NAICS, UNSPSC 
(version 3.01 et 7.3) et GEO. 



Voici le resultat renvoye a 1' utilisation de ce programme : 

new business saved 

1 business(es) found 

Services Web & compagnie 
ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

Ce programme a permis la creation d'une nouvelle entite nommee Services Web & compagnie. La cle 
qui lui a ete attribuee par l'annuaire est ba748c9d-73ce-4cd9-85f8-294edddcbbf0. 

La fonction save_service 

La fonction save_service permet de demander a l'operateur du site d'enregistrer ou de modifier un 
ou plusieurs services metier durant une seule et meme operation aupres de l'annuaire. 
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Le service metier doit referencer 1' entite metier dont il depend et cette entite doit etre controlee par le 
meme administrateur. Cette fonction peut etre egalement utilisee pour transferer un service d'une 
entite a une autre ou un modele de liaison d'un service a un autre. 

Voici la definition WSDL de F operation : 

<operation name="save_service"> 

<input message="tns:save_service"/> 

<output message="tns:serviceDetail "/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message save_servi ce est la suivante : 

<save_service generic="Z.O" xml ns="urn:uddi -org:api_v2" > 

<authInfo>5tr7'n<7</authInfo> 

<businessService/> [<businessService/>...] 
</save_service> 

L' element authlnfo contient le jeton d'authentification. 

Les elements businessService represented les services metier dans un ordre indifferent (sauf en cas 
de transfert d'un service metier ou d'un modele de liaison vers une autre entite metier, operation 
possible via l'utilisation de cette fonction par modification de cles). 

Cette fonction renvoie un message serviceDetail qui reflete le resultat final de l'operation et les 
informations nouvellement enregistrees dans l'annuaire. 

<serviceDetail generic="2.0" xmlns="urn:uddi-org:api_v2" 

operator="Str7Ajfi(" [truncated="true|fal se"]> 

<businessService/> [<businessService/>...] 
</serviceDetail > 

Demander I'enregistrement d'un service metier 
Exemple d'utilisation : 

import org.uddi4j . cl i ent.UDDI Proxy ; 

import org. uddi4j .datatype.*; 

import org.uddi4j .datatype. service. BusinessService; 

import org.uddi4j . datatype. tmodel .TModel ; 

import org. uddi4j .response.*; 

import org.uddi4j . transport. Transport Factory ; 

import org . uddi 4j . uti 1 .*; 

import Java. security. Security; 

import Java. util .Vector; 

public class UDDISaveServicel { 

public static void main(String[] args) throws Exception { 
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Au prealable, l'entite metier Services Web & compagnie de laquelle dependra le nouveau service 
metier qui va etre cree par ce programme est recuperee : 

Vector names = new VectorO; 
names .add (new Name( "service Web & compagnie")); 
BusinessList bl = proxy .find_business( 
names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. printlntbis. size( )+" business(es) found\n"); 
Vector biv = bis .getBusinessInfoVector( ) ; 
for (int i =0; i < biv.sizeO; i++) { 

Businesslnfo bi = (BusinessInfo)biv.elementAt(i ) ; 

Sy stem. out. println(bi .getNameStringC ) ) ; 

Sy stem. out. println(bi .getBusinessKey( )) ; 

Sy stem. out. println("\n") ; 

II s'agit ensuite decreerun nouveau service metier nomme Mon API de recherche UDDI ; celui-ci est 
rattache a l'entite metier Services Web & compagnie recuperee auparavant : 

BusinessService bs = new BusinessServiceC") ; 

names = new Vector( ) ; 

names. add(new NameC'Mon API de recherche UDDI")); 

bs . set NameVector( names) ; 

bs.setBusinessKey(bi .getBusinessKeyO) ; 

Vector bsdsv = new VectorO; 
Description bsd = new Description; 

"Mon service d'API de recherche UDDI."); 
bsdsv.addElement(bsd) ; 
bs.setDescriptionVectort bsdsv) ; 

Le code suivant est destine a categoriser le nouveau service metier qui va etre cree. Dans le cas present, 
le programme fait appel aux taxonomies de classification NAICS, UNSPSC (version 7.3) et GEO : 

Vector cbv = new VectorO; 

KeyedReference naics = new KeyedReferenceC'Information" , "51"); 

naics.setTModelKey(TModel.NAICS_TMODEL_KEY); 

cbv. addElement( naics) ; 

naics = new KeyedReference( 

"Information Services and Data Processing Services", "514"); 

nai cs . setTModel Key (TModel . NAICS_TMODEL_KEY) ; 

cbv. addElement( naics) ; 



naics = new KeyedReferenceC'Data Processing Services", 
naics. setTModel Key (TModel. NAICS_TMODEL_KEY); 
cbv. addElement( naics) ; 

KeyedReference unspsc = new KeyedReferencet 

"Communications and Computer Equipment and Periphera 
'•Supplies", "43.00.00.00.00"); 



"5142" 



s and Components and 
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unspsc. setTModel Key(TModel.UNSPSC_73_TM0DEL_KEY); 
cbv.addElement(unspsc) ; 
unspsc = new KeyedReference( 

"Internet and intranet software", "43.16.28.00.00"); 
unspsc. setTModel Key (TMode1.UNSPSC_73_TM0DEI._KEY); 
cbv. add Element (unspsc) ; 

KeyedReference geo = new KeyedReference( "France" , "FR"); 

geo. setTModel Key (TMode1.IS0_CH_TM0DEI._KEY); 

cbv.addElement(geo) ; 

geo = new KeyedReference("Ile-De-France", "FR-J"); 

geo. setTModel Key (TModel .ISO_CH_TMODEL_KEY) ; 

cbv.addElement(geo) ; 

geo = new KeyedReference("Hauts-De-Seine" , "FR-92"); 

geo. setTModel Key (TModel. ISO_CH_TMODEL_KEY); 

cbv.addElement(geo) ; 

CategoryBag cb = new CategoryBagt ) ; 
cb.setKeyedReferenceVector(cbv) ; 
bs.setCategoryBag(cb) ; 

Puis la fonction de sauvegarde d'un service metier save_servi ce est invoquee : 

Vector services = new VectorO; 

services. add(bs) ; 

ServiceDetail sd = proxy .save_service(at.getAuthInfoString( ) , services); 

System. out. printlnt "new service saved\n" ); 

Enfin a lieu la verification du resultat de la fonction de sauvegarde d'un service metier par appel de la 
fonction de recherche f i nd_servi ce : 

ServiceList si - proxy. find_service( 

bi .getBusinessKeyt ) , names, null, null, null, 0); 

Servicelnfos sis = si .getServiceInfos( ) ; 
if (sis.sizeO == 0) { 

System. out. printlnC'no service(s) found"); 

} 

else { 

System. out. println(sis. size( )+" service(s) found\n"); 
Vector siv = sis.getServicelnfoVectort ) ; 
for (int j = 0; j < siv.sizeO; j++) { 

Servicelnfo si = (Servicelnfo)siv.elementAtt j) ; 
System. out. printlnt si .getNameString( ) ) ; 
System. out. printlnt si .getServiceKey( ) ) ; 
System. out. printlnt "\n") ; 
} 



proxy .discard_authToken(at.getAuth!nfo( ) ) ; 



Cet exemple montre comment realiser Fenregistrement d'un nouveau service metier nomme Mon API 
de recherche UDDI. Ce nouveau service metier est rattache a une entite metier existante, dont le nom 
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est Services Web & compagnie, prealablement recherchee par l'appel d'une fonction find_business. 
Tout comme lors de la creation d'une entite metier etudiee dans Fexemple precedent, ou celle d'un 
service type illustree plus loin, il est possible d'utiliser plusieurs taxonomies de categorisation. Les 
memes categories et valeurs de taxonomies sont utilisees dans cet exemple et dans celui qui presente 
la creation d'un service type, mais cela n'est pas du tout obligatoire (taxonomies de classification 
NAICS, UNSPSC (version 7.3) et GEO). Voici le resultat renvoye a l'utilisation de ce programme : 

1 business(es) found 

Services Web & compagnie 
ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

new service saved 

1 service(s) found 

Mon API de recherche UDDI 
f2e2e98a-551b-45a6-be93-adl3e528f4ed 

Le resultat de ce programme se traduit par la creation d'un nouveau service metier nomme Mon API de 
recherche UDDI. La cle qui lui a ete affectee par l'annuaire est f2e2e98a-551b-45a6-be93-adl3e528f4ed. 

Ce nouveau service metier a eterattache a une entite metier dontlenom est Services Web & compagnie 
(cle ba748c9d-73ce-4cd9-85f8-294edddcbbf0). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R3001 : si un service metier est decrit par une balise wsdl : service (service decrit en format 
WSDL) qui se veut conforme au profil de base WS-I, ce service metier doit etre categorise comme etant conforme, 
c'est-a-dire que I'element categoryBag doit etre complete par I'ajout d'une keyedReference qui reference la 
categorie http://wwww.ws-i.0rg/pr0files/base/l .0 de la taxonomie externe ws - i -org : conf ormsTo. 



La fonction save_binding 

La fonction save_binding permet d'enregistrer ou de modifier un ou plusieurs modeles de liaison en 
une seule operation aupres de l'annuaire. 

Pour enregistrer un nouveau modele de liaison, il faut simplement laisser l'attribut de la cle vide. Si 
la cle est fournie, il s'agit d'une modification d'un modele de liaison existant. 

Voici la definition WSDL de 1' operation : 

<operation name="save_binding"> 

<input message="tns:save_binding"/> 

<output message="tns:bindingDetail "/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message save_binding est la suivante : 

<save_binding generic="2.0" xmlns="urn:uddi-org:api_v2"> 

<authInfo>5tr7'nsr</authInfo> 

<bi ndi ngTempl ate/> [<bi ndi ngTempl ate/>...] 
</save_binding> 
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L' element authlnfo contient le jeton d'authentification. 

Les elements bindingTemplate represented les modeles de liaison dans un ordre indifferent. 

Cette fonction renvoie le message bindingDetail qui contient le resultat final de l'operation et les 
informations nouvellement enregistrees dans l'annuaire. 

<bi ndi ngDetai 1 generic="2.0" xmlns="urn:uddi-org:api_v2" 

opera tor=" opera tor" [truncated="true|false"]> 

<bindingTempl ate/> [<bindingTempl ate/>...] 
</bindingDetail> 

Demander renregistrement d'un modele de liaison 
Exemple d'utilisation : 

import org.uddi4j . cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. Description; 

import org.uddi4j .datatype. Name; 

import org.uddi4j .datatype. binding.*; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import org . uddi 4j . uti 1 .*; 

import Java. security. Security ; 

import Java. util .Vector; 

public class UDDISaveBindingl { 

public static void main(String[] args) throws Exception { 

Le modele de liaison que nous allons creer reference un service type nomme servi cesweb-compagni e- 
com : i nqui ry, dont il faut d'abord rechercher la cle : 

TModelList tl = proxy .find_tModel ( 

"servicesweb-compagnie-com:inquiry" , null, null, null, ); 

TModel Infos tis = tl .getTModel Infost ) ; 
if (tis.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 

System. exit(O) ; 
} 

System. out .println(tis.size( )+" tmodel(s) found\n"); 

TModel Info ti = null; 

Vector tiv = tis. getTModel InfoVector( ) ; 

for (int i = 0; i < tiv.sizeO; i++) { 

ti = (TModel Info)tiv.elementAt(i ) ; 

System. out. println(ti .getNameString( ) ) ; 

System. out. printlntti .getTModel Key( )) ; 

System. out. println("\n" ) ; 
} 

Le modele de liaison que nous allons creer reference un service type nomme servi cesweb-compagni e- 
com : i nqui ry que nous avons localise, dont F implementation est realisee par un service metier propose 
par Fentite metier Services Web & compagnie : 
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Vector names = new VectorO; 

names .add (new Name( "service Web & compagnie")) ; 

BusinessList bl = proxy .find_business( 

names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

Afin de pouvoir realiser la mise a jour souhaitee, il faut auparavant s'enquerir, aupres de Foperateur 
du noeud UDDI, d'un jeton d'authentiflcation : 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. printlntbis. size( )+" business(es) found\n"); 
Vector biv = bis .getBusinessInfoVectort ) ; 
for (int i =0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtO' ) ; 

Sy stem. out. println(bi .getNameString( ) ) ; 

Sy stem. out. println(bi .getBusinessKey( )) ; 

Sy stem. out. println("\n") ; 

Apres avoir localise Fentite metier, il faut rechercher le service metier Mon API de recherche UDDI 
propose par cette entite, qui constitue F implementation du service type servicesweb-compagnie- 
com: i nqui ry precedemment identifie : 

names = new Vector( ) ; 

names. add(new NameC'Mon API de recherche UDDI")); 

ServiceList si = proxy. find_service( 

bi .getBusinessKeyO , names, null, null, null, 0); 

Servicelnfos sis = si .getServicelnfosC ) ; 
if (sis.sizeO == 0) { 

System. out. printlnC'no service(s) found"); 
} 
else { 

System. out .printlntsis .size( )+" service(s) found\n"); 
Vector siv = sis.getServicelnfoVectort ) ; 
for (int j = 0; j < siv.sizeO; j++) { 

Servicelnfo si = (Servicelnfo)si v.elementAt( j ) ; 
System. out. println( si .getNameString( ) ) ; 
System. out. printlnt si .getServiceKey( ) ) ; 
System. out. println( "\n" ) ; 

Le service metier a ete trouve : le modele de liaison peut alors etre cree. Dans le cas present, le point 
d'acces a F implementation represente une application HTTP dont FURL fournie est http://monserveur: 
80/mawebapplication/servlet/rpcrouter: il s'agit en pratique d'une URL typique d'une application Java 
(servl et) qui utilise une implementation SOAP Apache (rpcrouter). 

BindingTempl ate bt = new BindingTemplate( ) ; 
bt.setBindingKeyC" ) ; 
bt.setServiceKey(si .getServiceKeyO) ; 
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TModel Instancelnfo tmii = new TModel InstanceInfo( ) ; 

tmii.setTModelKey(ti.getTModelKeyO); 

TModel InstanceDetails tmid = new TModel InstanceDetails( ) ; 

Vector bttiiv = new VectorO; 

bttiiv.addElement(tmii ) ; 

tmid.setTModel Instance I nfoVector( bttiiv) ; 

bt.setTModel InstanceDetails(tmid) ; 

Vector btdsv = new VectorO; 
Description btd = new Description( 

"URL de mon instance d'API de recherche UDDI " > ; 
btdsv. add Element (btd) ; 
bt. set DescriptionVector( btdsv) ; 

AccessPoint accessPoint = new AccessPointC 

"http://monserveur:80/mawebapplication/servlet/rpcrouter" , 
"HTTP (Hypertext Transfer Protocol)"); 

bt.setAccess Point (access Point) ; 

Ensuite, le nouveau modele de liaison ainsi cree est sauvegarde : 

Vector bindings = new VectorO; 
bindings. add(bt) ; 

BindingDetail bd = proxy .save_binding( 
at.getAuthInfoString( ) , bindings) ; 
System. out. printlnt "new binding template saved\n" ); 

Enfin, le resultat de la fonction de sauvegarde d'un modele de liaison est verifie a Faide de l'appel de 
la fonction de recherche f i nd_bi ndi ng : 

TModel Bag tb = new TModel BagO; 

tb. add (new TModel Key(ti .getTModelKeyO) ) ; 

bd = proxy .find_binding(null , si .getServiceKeyO, tb, 0); 

Vector bdv = bd.getBindingTemplateVector( ) ; 
if (bdv.sizeO == 0) { 

System. out. printlnC'no binding(s) found"); 
} 
el se { 

System. out. println(bdv.size()+" binding(s) found\n"); 
for (int k = 0; k < bdv.sizeO; k++) { 
bt = (BindingTempl ate)bdv.elementAt(k) ; 
System. out .println(bt.getDefaul tDescriptionStringt )) ; 
System. out .println(bt.getBindingKey( ) ) ; 
System. out .print ln("\n" ) ; 
} 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 



Cet exemple illustre la creation d'un modele de liaison. Le programme commence tout d'abord par 
rechercher le service type servicesweb-compagnie-com:inquiry, a l'aide de la fonction find_tModel, 
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pour lequel on souhaite creer une reference d'implementation. Ensuite, il est necessaire de localiser 
Fentite metier Services Web & compagnie, a F aide de la fonction find_business, dontl'undes services 
metier constitute une implementation de ce service type. En cas de succes, un jeton d'authentification 
est alors demande aupres de l'operateur du site par Fintermediaire de la fonction get_authToken. 
Puis, le programme cherche a recuperer le service metier Mon API de recherche UDD I, via la fonction 
f i nd^servi ce, qui implemente le service type en question. Lorsque le service metier a ete trouve, il ne 
reste plus qu'a creer F instance du nouveau modele de liaison, puis a la sauvegarder via la fonction 
save_binding proprement dite. Le programme verifie alors le resultat de cette creation d'un modele 
de liaison par Fintermediaire de la fonction f i nd_bi ndi ng. Finalement, le programme se termine par 
un appel a la fonction discard_authToken afin de liberer le jeton d'authentification prealablement 
acquis aupres de l'operateur du nceud UDDI. 

II s'agit bien de la creation d'un nouveau modele de liaison : la valeur de la cle n'est pas fournie. 
Voici le resultat renvoye a Futilisation de ce programme : 

1 tmodel (s) found 

servicesweb-compagnie-com: inquiry 
uuid:lec88662-04b6-4231-a47f-39529db6f22c 

1 business(es) found 

Services Web & compagnie 

ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

1 service(s) found 

Mon API de recherche UDDI 
f2e2e98a-551b-45a6-be93-adl3e528f4ed 

new binding template saved 

1 binding(s) found 

URL de mon instance d'API de recherche UDDI 
0496fb69-1484-44cb-bc50-9el09f9feb9b 

Ce programme a creeun nouveau modele de liaison nomme URL de mon instance d'API de recherche 
UDDI. La cle qui lui a ete affectee par Fannuaire est 0496f b69-1484-44cb-bc50-9el09f9feb9b. 

Ce nouveau modele de liaison constitue une nouvelle implementation du service type, dont la cle est 

uuid:lec88662-04b6-4231-a47f-39529db6f22c, par le service metiernomme Mon API de recherche UDDI 
(cle f2e2e98a-551b-45a6-be93-ad!3e528f4ed). 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R3000 : si un service metier est decrit par une balise wsdl : service (service decrit en format 
WSDL), il faut veiller, lorsque ce service metier est enregistre, a ce que chaque modele de liaison corresponde a 
une balise wsdl : port et que chaque balise possede son modele de liaison correspondant. Cette correspondance 
est etablie seulement si, d'un point de vue lexical, la valeur de I'attribut accessPoint (bindingTemplate) est 
identique a celle de I'attribut location (wsdl :port). 



La fonction save_tModel 

La fonction save_tModel permet de demander a l'operateur du site d'enregistrer ou de modifier un ou 
plusieurs services types en une seule operation sur Fannuaire. 
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Voici la definition WSDL de F operation : 

<operation name="save_tModel "> 

< input message="tns:save_tModel "/> 

<output message="tns :tModel Detail "/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message save_tModel est la suivante : 

<save_tModel generic="2.0" xmlns="urn:uddi -org:api_v2"> 

<authInfo>StrfAjg</authInfo> 

<tModel/> [<tModel />...] 
</save_tModel> 

L' element authlnfo contient le jeton d'authentification. 

Les elements tModel represented les services types dans un ordre indifferent. S'il s'agit de modifier 
un service type deja enregistre, il est necessaire de fournir sa precedente cle. 

Cette fonction renvoie un message tModel Detai 1 , reflet des mises a jour operees dans l'annuaire. 

<tModelDetail generic="2.0" xmlns="urn:uddi-org:api_v2" 

operator="Str7Ajfi(" [truncated="true|fal se"]> 

<tModel/> [<tModel />...] 
</tModel Detai 1> 

Demander renregistrement d'un service type 

Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org. uddi4j .datatype.*; 

import org.uddi4j . datatype. tmodel .TModel ; 

import org. uddi 4j .response.*; 

import org. uddi 4 j .transport .Transport Factory ; 

import org . uddi 4j . uti 1 .*; 

import Java. security. Security; 

import Java. util .Vector; 

public class UDDISaveTModel 1 { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken("user" , "password"); 

II s'agit tout d'abord de creer un nouveau service type nomme servi cesweb-compagni e-com: i nqui ry : 
ici, il s'agit bien d'une creation, car la cle n'est pas fournie. 

TModel tm = new TModel ("", "servicesweb-compagnie-com:inquiry") ; 

Vector tmdsv = new VectorO; 

Description tmd = new Description; 

"API de recherche UDDI 2.0 - Duplication de la version officielle") ; 

tmdsv.addElement(tmd) ; 

tm.setDescript ion Vector (tmdsv) ; 
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OverviewURL oURL - 

new OverviewllRLt "http://www.uddi .org/wsdl/inquire_v2.wsdl") ; 
OverviewDoc oDoc = new OverviewDoct ) ; 
oDoc.setOverviewURL(oURL) ; 

Vector oddsv = new VectorO; 

Description odd = new Description( 

"Fonctions de l'API de recherche pour interroger un annuaire UDDI . " ) ; 

oddsv. add Element (odd) ; 

oDoc.setDescript ion Vector (oddsv) ; 

tm.setOverviewDoc(oDoc) ; 

Le code ci-apres est destine a categoriser le nouveau service type qui va etre cree. Dans le cas present, 
le programme fait appel aux taxonomies de classification NAICS, UNSPSC (version 7.3) et GEO : 

Vector cbv = new VectorO; 

KeyedReference naics = new KeyedReferenceCInformation" , "51"); 
naics. setTModel Key (TModel. NAICS_TMODEL_KEY); 
cbv. addElementt naics) ; 
naics = new KeyedReferencet 

"Information Services and Data Processing Services", "514"); 
naics.setTModelKey(TModel.NAICS_TMODEL_KEY); 
cbv. addElementt naics) ; 

naics = new KeyedReferencet "Data Processing Services", "5142"); 
naics. setTModelKeytTModel .NAICS_TMODEL_KEY) ; 
cbv. addElementt naics) ; 



KeyedReference unspsc = new KeyedReferencet 

"Communications and Computer Equipment and Peripheral 
"43.00.00.00.00"); 

unspsc. setTModel Key (TModel .UNSPSC_73_TM0DEL_KEY) ; 

cbv. addElementt unspsc) ; 

unspsc = new KeyedReferencet 

"Internet and intranet software", "43.16.28.00.00"); 

unspsc. setTModel Key (TModel. UNSPSC_73_TM0DEL_KEY); 

cbv. addElementt unspsc) ; 

KeyedReference geo = new KeyedReferenceC'France" , "FR"); 

geo . setTModel Key (TModel . ISO_CH_TMODEL_KEY ) ; 

cbv.addElementtgeo) ; 

geo - new KeyedReferenceC'Ile-De-France" , " FR- J " ) ; 

geo .setTModel Key (TModel . ISO_CH_TMODEL_KEY ) ; 

cbv.addElementtgeo) ; 

geo = new KeyedReference("Hauts-De-Seine" , "FR-92"); 

geo .setTModel Key (TModel . ISO_CH_TMODEL_KEY ) ; 

cbv.addElementtgeo) ; 

CategoryBag cb = new CategoryBag( ) ; 
cb.setKeyedReferenceVectortcbv) ; 
tm.setCategoryBagtcb) ; 

La fonction de sauvegarde d'un service type save_tModel est appelee : 

Vector tModels = new VectorO; 

tModel s.addttm) ; 

TModelDetail tmld = proxy. save_tModel (at. getAuthlnfoStringt ) , tModels) 

System. out. printlnt "new tmodel saved\n"); 



s and Components and Supplies" 
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Puis la fonction de recherche d'un service type find_tModel est appelee afin de verifier le resultat de 
la fonction de creation : 

TModelList tl = proxy. f i nd_tModel ( 

"servicesweb-compagnie-com:inquiry" , null, null, null, 0); 

TModellnfos tis = tl .getTModel Infos( ) ; 
if (tis.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 
} 
el se { 

System. out. println(tis .size( )+" tmodel(s) found\n"); 
Vector tiv = tis. getTModel InfoVectort ) ; 
for (int i = 0; i < tiv.sizeO; i++) { 

TModellnfo ti = (TModel Info)tiv.elementAt(i ) ; 
System. out. println(ti . get NameSt ring ( )) ; 
System. out. pn" ntl n ( ti .getTModel Key( ) ) ; 
System. out. println( "\n" ) ; 
} 
} 

proxy .discard_authToken(at.getAuthInfo( ) ) ; 
} 
} 

Cet exemple illustre Fenregistrement d'un nouveau service type nomme servi cesweb-compagni e- 
com : i nqui ry : la cle du service n'est pas fournie. Tout comme cela est possible lors de la creation d'une 
entite metier ou d'un service metier, fonctions que nous avons etudiees dans les exemples precedents, 
cet exemple utilise plusieurs taxonomies de categorisation. 

Les memes categories et valeurs de taxonomies peuvent etre utilisees pour ces differentes structures 
de donnees UDDI, mais ceci n'est pas une obligation : les taxonomies doivent etre utilisees avec 
discernement en fonction du spectre couvert par la structure de donnees consideree. La portee d'une 
entite metier est differente de celle d'un service metier fourni par cette meme entite. II en est de 
meme pour un service type. La problematique d'utilisation des taxonomies peut s'apparenter a la 
maniere d'effectuer le referencement d'un site Web sur Internet. Voici le resultat renvoye a l'utilisation 
de ce programme : 

new tmodel saved 

1 tmodel (s) found 

servi cesweb-compagni e-com: i nqui ry 
uuid:lec88662-04b6-4231-a47f-39529db6f22c 

Ce programme a permis de creer un nouveau service type nomme servi cesweb-compagni e-com: i nqui ry. 
La cle qui lui a ete attribuee par l'annuaire est uui d : Iec88662-04b6-4231-a47f-39529db6f 22c. 

Ce service type est maintenant pret a etre reference par un modele de liaison. 
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Avertissement 

Cet exemple est essentiellement didactique, mais n'est pas correct sur le fond : nous venons tout simplement de 
creer une copie totalement officieuse du service type de I'API de recherche UDDI (Inquiry API), propriete du 
consortium UDDI. Cette copie reference le meme modele abstrait que le service type officiel : http://www.uddi.org/ 
wsdl/inquire_v2.wsdl. Ceci ne respecte pas un principe elementaire de la reutilisation. En effet, dans le domaine 
des services Web, le modele abstrait constitue I'unite elementaire de reutilisation : il est done inefficace et contre- 
productif de dupliquer le service type qui reference un tel modele abstrait. 



RecommandationsWS-l Basic Profile 1.0 (draft) 

Recommandation R3002 : un service Web conforme au profil de base WS-I doit etre imperativement decrit en 
langage WSDL et reference en tant que tel par le service type qui porte sa definition. Le service type doit done etre 
enregistre avec un element overvi ewDoc, lequel doit comporter un element overvi ewURL qui pointe sur un docu- 
ment WSDL, lui-meme conforme au profil de base WS-I (voir document Besf Practices: Using WSDL in a UDDI 
Registry, Version 1.08 a I'adresse http://www.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using- 
wsdl-v108-20021110.htm). 

Recommandation R3003 : un service type conforme au profil de base WS-I doit etre imperativement categorise 
comme porteur d'une description de service en langage WSDL, e'est-a-dire que I'element categoryBag doit etre 
complete par I'ajout d'une keyedRef erence qui reference la categorie wsdl Spec de la taxonomie interne uddi - 
org:types. 

Recommandation R3004 : un service type conforme au profil de base WS-I doit etre imperativement congu en 
adequation par rapport aux elements wsdl : binding qu'il reference, ce qui signifie que I'element categoryBag 
doit etre complete par I'ajout d'une keyedReference qui reference la categorie http://wwww.ws-i.org/profiles/ 
base/1.0 de la taxonomie externe ws-i -orgrconformsTo si la liaison WSDL referencee se declare elle-meme 
conforme au profil de base WS-I. 

Recommandation R3005 : aucune structure UDDI autre qu'un service type ne peut etre etiquetee comme 
conforme au profil de base WS-I (cette recommandation semble cependant etre en conflit avec la recommandation 
R3001 qui prevoit qu'un service metier peut egalement etre etiquete de cette maniere). 



Les fonctions de suppression 

Les quatre fonctions de suppression permettent de supprimer les instances des quatre principales 
structures de donnees UDDI dont nous venons d'aborder les moyens de creation ou de mise a jour. 

La fonction delete_business 

La fonction del ete_busi ness permet de supprimer une ou plusieurs entites metier en une seule operation. 
La definition WSDL de 1' operation est la suivante : 

<operation name= "del ete_busi ness "> 

<input message="tns: del ete_busi ness "/> 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 
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Syntaxe des messages 

La syntaxe du message del ete_business est la suivante : 

<delete_business xmlns="urn:uddi -org:api_v2" generic="2.0"> 

<authInfo>St/"7/ig</authInfo> 

<businessKey>5ir7'ng</businessKey> 

[<businessKey>Str7'n£7</businessKey>...] 
</delete_business> 

U element authlnfo contient le jeton d'authentification. 

Les elements businessKey contiennent les cles des entites metier a supprimer au cours de la meme 
operation. 

Cette fonction renvoie un message dispositionReport (voir fonction discard_authToken) qui donne 
le resultat de 1' operation. 

Demander la suppression d'une ou plusieurs entites metier 

Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import Java. security. Security ; 

import Java. util .Vector; 

public class UDDIDeleteBusinessl { 

public static void main(String[] args) throws Exception { 

Vector names = new VectorO; 
names. add(new Name( "service Web & compagnie" )) ; 
BusinessList bl = proxy .find_business( 
names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. println(bis. sizeC )+" business(es) found\n"); 
Vector biv = bis.getBusinessInfoVectort ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 

System. out .println(bi . getNameString( ) ) ; 

System. out. printlntbi .getBusinessKeyt )) ; 

DispositionReport dr = proxy .delete_business( 
at.getAuthInfoString( ) , bi .getBusinessKey( ) ) ; 

System. out. printlnC'business deleted : "+dr.success( ) ) ; 

System.out.println("\n" ) ; 
} 
proxy .discard_authToken(at.getAuth!nfo( ) ) ; 
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Cet exemple montre comment supprimer une entite metier nominee Services Web & compagnie. Le 
programme recherche l'existence de l'entite metier qui doit faire l'objet d'une suppression par la 
fonction f i nd_biisiness. En cas de succes, un jeton d'authentification est demande aupres de l'operateur 
du site via la fonction get_authToken. Puis, la fonction de suppression proprement dite est activee 
avec le jeton d'authentification, accompagne de la cle de l'entite metier trouvee, passes en parametres. 
Enfin, le programme fait appel a la fonction di scard_authToken pour liberer le jeton d'authentification 
prealablement acquis. Voici le resultat renvoye a l'utilisation de ce programme : 

I 1 business(es) found 

Services Web & compagnie 
ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

business deleted : true 

Par F intermediate de ce programme, l'entite metier Services Web & compagnie, dont la cle etait 
ba748c9d-73ce-4cd9-85f8-294edddcbbf 0, a bien ete supprimee. 

La fonction delete_service 

La fonction del ete_servi ce est utilisee pour supprimer un ou plusieurs services metier au cours d'une 
seule et meme operation. 

La definition WSDL de 1' operation est la suivante : 

<operation name="delete_service"> 

<input message="tns:delete_service"/> 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe de ce message est la suivante : 

<delete_service gene ric=" 2.0" xmlns="urn:uddi-org:api_v2"> 

<authInfo>Str7Ajg</authInfo> 

<servi ceKey>Si/"7'ng</servi ceKey> 

[<serviceKey>Str7'ng</serviceKey> ...] 
</delete_service> 

L'element authlnfo contient le jeton d'authentification. 

Les elements serviceKey contiennent les cles des services metier a supprimer au cours de la meme 
operation. 

Cette fonction renvoie un message dispositionReport (voir la section consacree a la fonction 
di scard_authToken) qui donne le resultat de l'operation. 

Demander la suppression d'un ou plusieurs services metier 
Exemple d' utilisation : 

I import org.uddi4j .cl i ent.UDDI Proxy ; 
import org.uddi4j .data type. Name; 
import org. uddi4j .response.*; 
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import org.uddi4j . transport. Transport Factory ; 
import Java. security. Security ; 
import Java. util .Vector; 

public class UDDIDeleteServicel { 

public static void main(String[] args) throws Exception { 

Vector names = new VectorO; 
names. add(new Name( "service Web & compagnie")) ; 
BusinessList bl = proxy .find_business( 
names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 

} 

A ce niveau, l'entite metier Servi ces Web & compagni e a ete localisee. Un jeton d'authentification est 
demande aupres de l'operateur du noeud UDDI, afin de pouvoir proceder a la suppression du service 
metier qu'il reste a localiser : 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out .println(bis.size( )+" business(es) found\n"); 
Vector biv = bis.getBusinessInfoVector( ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 

System. out . println(bi .getNameString( ) ) ; 

System. out . printlntbi .getBusinessKeyC )) ; 

System.out.println("\n" ) ; 

names = new Vectort ) ; 

names. add(new NameC'Mon API de recherche UDDI")); 

Servi ceLi st si = proxy. find_service( 

bi .getBusinessKeyO , names, null, null, null, 0); 

Servicelnfos sis = si .getServicelnfost ) ; 
if (sis.sizeO == 0) { 

System. out. pri ntl n( "no service(s) found"); 
} 
else { 

Le service metier a supprimer est localise : il ne reste plus qu'a demander sa destruction. Une boucle 
de suppression est realisee car plusieurs services metier peuvent porter le meme nom (Fidentifiant 
d'un service metier est un UUID) et la distinction entre les differences instances est inutile : 

System. out. println(sis. size( )+" service(s) found\n"); 
Vector siv = sis.getServicelnfoVectorO ; 
for (int j = 0; j < siv.sizeO; j++) { 

Servicelnfo si = (Servicelnfo)si v.elementAtt j) ; 

System. out. pri ntl n( si .getNameString( )) ; 

System. out. pri ntl n( si .getServiceKey( )) ; 

DispositionReport dr = proxy .del ete_service( 
at.getAuthInfoString( ) , si .getServiceKeyO) ; 

System. out. pri ntl n( "service deleted : "+dr.success( ) ) ; 
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System. out. print! n( "\n") ; 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 



) 



Cet exemple montre comment supprimer un ou plusieurs services metier, dont le nom est Mon API de 
recherche UDDI, implemente(s) parune entite metier nommee Services Web & compagnie. Le programme 
commence par rechercher 1' entite metier censee controler le service metier a l'aide de la fonction 
find_business. En cas de succes, un jeton d'authentification est demande aupres de l'operateur du 
site via la fonction get_authToken. Puis, le programme recherche Fexistence du service metier qui 
doit faire l'objet d'une suppression par la fonction find_service. C'est alors seulement que la fonc- 
tion de suppression proprement dite est activee avec le jeton d'authentification, accompagne de la cle 
du service metier trouvee, passes en parametres. Enfin, le programme fait appel a la fonction 
discard_authToken qui permet de liberer le jeton d'authentification prealablement acquis aupres de 
l'operateur du nceud UDDI. Voici le resultat renvoye a l'utilisation de ce programme : 

1 business(es) found 

Services Web & compagnie 
ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

1 service(s) found 

Mon API de recherche UDDI 
f2e2e98a-551b-45a6-be93-adl3e528f4ed 

service deleted : true 

Par 1' intermediate de ce programme, le service metier nomme Mon API de recherche UDDI, dont la 
cle etait f2e2e98a-551b-45a6-be93-adl3e528f4ed, a bien ete supprime. 

La fonction delete_binding 

La fonction del ete_bi ndi ng est utilisee pour supprimer un ou plusieurs modeles de liaison. 
La definition WSDL de 1' operation est la suivante : 

<operation name="delete_binding"> 

<input message="tns:delete_binding'7> 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message del ete_binding est la suivante : 

<delete_binding gene ric=" 2.0" xmlns="urn:uddi-org:api_v2"> 

<authInfo>5tr7'nsr</authInfo> 

<bi ndi ng Key >Str i ng</bi ndi ngKey> 

[<bindingKey>Str7'ng</bindingKey>. . .] 
</delete_binding> 

Lelement authlnfo contient le jeton d'authentification. 



Publier un service 

Chapitre 12 

Les elements bindingKey contiennent les cles des modeles de liaison a supprimer au cours de la 
meme operation. 

Cette fonction renvoie un message dispositionReport (voir la section consacree a la fonction 
discard_authToken) qui donne le resultat de l'operation. 

Demander la suppression d'un ou plusieurs modeles de liaison 
Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

i mport org . uddi 4j .datatype . bi ndi ng . Bi ndi ngTempl ate ; 

import org. uddi 4j .response.*; 

import org. uddi 4 j . transport. Transport Factory ; 

import org. uddi 4j .util .*; 

import Java. security. Security; 

import Java. util .Vector; 

public class UDDIDel eteBindingl { 

public static void main(String[] args) throws Exception { 

Le programme recherche tout d'abord le service type nomme servicesweb-compagnie-com:inquiry 
reference par le(s) modele(s) de liaison a supprimer : 

TModelList tl = proxy. f i nd_tModel ( 

"servicesweb-compagnie-comrinquiry" , null, null, null, ); 

TModellnfos tis = tl .getTModel Infos( ) ; 
if (tis.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 

System. exit(0) ; 
} 

System. out. println(tis. size( )+" tmodel(s) found\n"); 

TModel Info ti = nul 1 ; 

Vector tiv = tis. getTModel InfoVector( ) ; 

for (int i = 0; i < tiv.sizeO; i++) { 

ti = (TModel Info)tiv.elementAt(i ) ; 

System. out. printlntti .getNameString( ) ) ; 

System. out. printlntti .getTModel Key( ) ) ; 

System.out.println("\n" ) ; 
} 

Lorsque le service type a ete trouve, le programme recherche le service metier Mon API de recherche 
UDDI, lequel contient le(s) modele(s) de liaison a supprimer : 

Vector names = new VectorO; 

names. add(new NameC'Mon API de recherche UDDI")); 

ServiceList si - proxy. find_service(nul 1 , names, null, null, null, 0); 

Servicelnfos sis = si .getServicelnfost ) ; 
if (sis.sizeO == 0) { 

System. out. printlnC'no service(s) found"); 

System. exit(0) ; 
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A ce niveau, le service metier a ete localise : le programme demande a l'operateur du nceud UDDI un 
jeton d'authentification afin d'etre en mesure de realiser la suppression souhaitee, puis recherche le(s) 
modele(s) de liaison contenu(s) par le service metier qui reference(nt) le service type servicesweb- 
compagnie-com: inquiry trouve precedemment. 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. println(sis. size( )+" service(s) found\n"); 
Vector siv = sis.getServiceInfoVector( ) ; 
for (int i =0; i < siv.sizeO; 1++) ( 

Servicelnfo si = (Servicelnfo)siv.elementAt(i ) ; 

System. out. println( si .getNameString( ) ) ; 

System. out. println( si .getServiceKey( ) ) ; 

Sy stem. out. println("\n") ; 

TModelBag tb = new TModelBagO; 

tb . add ( new TModel Key ( ti . getTModel Key ( ) ) ) ; 

BindingDetail bd = proxy .find_binding(nul 1 , si .getServiceKeyO, tb, 0); 

Vector bdv = bd.getBindingTemplateVectort ) ; 
if (bdv.sizeO == 0) { 

System. out. printlnC'no binding(s) found"); 
} 
el se { 

Le service metier contient un ou plusieurs modeles de liaison. Pour supprimer tous les modeles de 
liaison du service metier, il faut mettre en ceuvre une boucle de suppression : 

System. out. println(bdv. size( )+" binding(s) found\n"); 
for (int j = 0; j < bdv.sizeO; j++) { 

BindingTempl ate bt = (BindingTemplate)bdv.elementAt( j ) ; 

System. out. println(bt.getDefaultDescriptionString( )) ; 

System. out. println(bt.getBindingKey( )) ; 

DispositionReport dr = proxy. delete_binding( 
at.getAuthlnfoStringt ) , bt.getBindingKey( )) ; 

System. out. pri ntl n( "binding template deleted : "+dr.success( ) ) ; 

System. out. println( "\n" ) ; 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 

} 

} 

Cet exemple montre comment supprimer un modele de liaison. Le programme commence tout 
d'abord par rechercher le service type nomme servicesweb-compagnie-com:inquiry, a l'aide de la 
fonction find_tModel, pour lequel on souhaite supprimer toutes les references d' implementation, 
materialisees par un ou plusieurs modeles de liaison. Ensuite, le programme cherche a recuperer 
le service metier nomme Mon API de recherche UDDI, via la fonction find_service, qui implemente le 
service type que nous venons de localiser. En cas de succes, un jeton d'authentification est alors 
demande aupres de l'operateur du site par F intermediate de la fonction get_authToken. II reste 
ensuite a parcourir la collection des modeles de liaison du service metier qui implementent le service 
type duquel on souhaite supprimer les references d' implementation, a l'aide de la fonction 
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f i nd_bi ndi ng. Pour chaque occurrence trouvee, la fonction de suppression del ete_bi ndi ng proprement 
dite est activee avec le jeton d'authentiflcation, accompagne de la cle du modele de liaison trouve, 
passes en parametres. Enfin, le programme se termine par un appel a la fonction discard_authToken 
afin de liberer le jeton d'authentiflcation prealablement acquis aupres de l'operateur du nceud UDDI. 
Voici le resultat renvoye a l'utilisation de ce programme : 

1 tmodel (s) found 

servicesweb-compagnie- com: inquiry 
uuid:lec88662-04b6-4231-a47f-39529db6f22c 

1 service(s) found 

Mon API de recherche UDDI 
f2e2e98a-551b-45a6-be93-adl3e528f4ed 

1 binding(s) found 

URL de mon instance d'API de recherche UDDI 
0496fb69-1484-44cb-bc50-9el09f9feb9b 

binding template deleted : true 

En conclusion, par l'intermediairedece programme, le modele de liaison URL de mon instance d'API 
de recherche UDDI, dont la cle etait 0496fb69-1484-44cb-bc50-9el09f 9feb9b, qui materialisait l'imple- 
mentation du service type servicesweb-compagnie- com: inquiry decle uuid:lec88662-04b6-4231-a47f- 
39529db6f22c par le service metier nomme Mon API de recherche UDDI de cle f2e2e98a-551b-45a6- 
be93-adl3e528f4ed, abienete supprime. 

La fonction delete_tModel 

La fonction del ete_tModel a pour objet de supprimer un ou plusieurs services types. 
La definition WSDL de 1' operation est la suivante : 

<operation name="delete_tModel "> 

<input message="tns:delete_tModel "/> 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message del ete_tModel est la suivante : 

<delete_tModel generic="2.0" xmlns="urn:uddi-org:api_v2"> 

<authInfo>Str7/)g</authInfo> 

<tModel Key>Str7'ng</tModel Key> 

[<tModel Key>Strfng</tModel Key> ...] 
</delete_tModel> 

Lelement authlnfo contient le jeton d'authentiflcation. 

Les elements tModel Key contiennent les cles des services types a supprimer au cours de la meme 
operation. 

Cette fonction renvoie un message dispositionReport (voir la section consacree a la fonction 
discard_authToken) qui donne le resultat de l'operation. 
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Demander la suppression d'un ou plusieurs services types 
Exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org. uddi 4 j .response.*; 

import org. uddi 4 j .transport. Transport Factory; 

import j a va. security .Security ; 

import Java. util .Vector; 

public class UDDIDeleteTModel 1 { 

public static void main(String[] args) throws Exception { 

TModelList tl = proxy. f i nd_tModel ( 

"servicesweb-compagnie-com:inquiry" , null, null, null, 0); 

TModel Infos tis = tl .getTModel Infos( ) ; 
if (tis.sizeO == 0) { 

System. out. printlnC'no tmodel(s) found"); 

System. exit(0) ; 
} 

AuthToken at = proxy .get_authToken("user" , "password"); 

System. out. printlnttis. size( )+" tmodel(s) found\n"); 
Vector tiv - tis. getTModel InfoVector( ) ; 
for (int i =0; i < tiv.sizeO; i++) { 

TModel Info ti = (TModel Info)ti v. elementAt(i ) ; 

System. out. print! n(ti .getNameStringC ) ) ; 

System. out. println(ti .getTModel Key( ) ) ; 

DispositionReport dr = proxy .del ete_tModel ( 
at.getAuthlnfoStringt ) , ti .getTModel KeyO) ; 

System. out .printlnC'tmodel deleted : "+dr.success( ) ) ; 

System. out .print! n("\n") ; 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 



) 



Cet exemple montre comment supprimer un ou plusieurs services types dont le nom est servi cesweb- 
compagni e-com: i nqui ry. Le programme commence par rechercher F existence du service type qui doit 
faire l'objet d'une suppression a Faide de la fonction find_tModel. En cas de succes, un jeton 
d'authentification est demande aupres de Foperateur du site via la fonction get_authToken. Puis la 
fonction de suppression delete_tModel proprement dite est activee avec le jeton d'authentification, 
accompagne de la cle du service type trouve, passes en parametres. 

Enfin, le programme utilise la fonction discardjuthToken arm de liberer le jeton d'authentification 
prealablement acquis aupres de Foperateur du site. Voici le resultat renvoye a Futilisation de ce 
programme : 

1 tmodel (s) found 

servi cesweb-compagni e-com: inquiry 
uuid:lec88662-04b6-4231-a47f-39529db6f22c 

tmodel deleted : true 
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Par l'intermediaire de ce programme, le service type servi cesweb-compagni e-com: i nqui ry, dont la cle 
etait uuid:lec88662-04b6-4231-a47f-39529db6f22c abienete supprime. 



Suppression logique des services types 

Comme nous I'avons vu precedemment, le modele d'un annuaire UDDI est constitue de deux categories d'objets 
racine : les entites metier et les services types. Les entites metier contiennent des services metier (0 a n) qui eux- 
memes contiennent des modeles de liaison (0 a n). Ce sont ces derniers modeles de liaison qui referenced les 
services types implements par ces services metier. 

Que se passe-t-il si Ton cherche a supprimer physiquement un service type ? II est impossible de faire cela sans 
rompre I'integrite referentielle de I'annuaire. Si le service type n'est reference dans aucune autre structure d'informa- 
tion de I'annuaire, c'est-a-dire des structures de type categoryBag, identifierBag ou tModel Instancelnfo, il 
n'est pas pour autant physiquement supprime. II est seulement supprime logiquement, c'est-a-dire qu'il est maintenu 
dans le systeme de persistance des donnees de I'annuaire et qu'il est invisible a certaines fonctions de recherche. 
Le service type, ainsi masque, reste visible de son seul proprietaire via la fonction get_registeredInfo etudiee 
plus haut dans ce chapitre. Le service type n'apparait notamment plus dans les requetes a destination de 
I'annuaire effectuees via la fonction f ind_tModel . Les details du service type restent cependant accessibles a 
tout utilisateur de I'annuaire par l'intermediaire de la fonction get_tModel Detail. Pour eviter cet acces a des 
donnees obsoletes, la specification UDDI recommande que I'auteur d'un service type le sauvegarde une derniere 
fois avec des valeurs annulees par la fonction saveJModel avant de le supprimer. Evidemment, les services 
metier qui referengaient le service type annule deviennent eux-memes obsoletes. II est possible de rendre a 
nouveau visible un service type masque en utilisant la fonction save_tModel , apres avoir pris soin d'affecter la cle 
du service type masque au nouveau service type. 



Les fonctions de gestion des assertions 

Les cinq fonctions de gestion des assertions ont ete ajoutees dans la version 2.0 de l'API UDDI et 
prennent en charge la gestion des instances d'une nouvelle structure de donnees creee a cette occasion : 
l'assertion d'administrateur (publisherAssertion). 

La fonction get_publisherAssertions 

La fonction getjublisherAssertions permet a l'utilisateur d'obtenir les assertions de sa collection 
d' assertions existantes (voir la remarque « Relations entre entites metier »). 

La definition WSDL de 1' operation est la suivante : 

<operation name="get_pub1 isherAssertions"> 

<input message="tns:get_publ is her Assertions"^ 

<output message="tns:publ isherAssertions"/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message get_publ i sherAsserti ons est la suivante : 

|<get_publ i sherAsserti ons generic="2.0" xmlns="urn:uddi -org:api_v2"> 
<authInfo>Str7'ng</authInfo> 
</get_publ isherAssertions> 
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L'element authlnfo contient le jeton d'authentification. 

Cette fonction renvoie un message publisherAssertions qui contient une ou plusieurs assertions 
publ i sherAsserti on selon le resultat de la requete : 

<publ i sherAsserti ons xmlns="urn:uddi-org:api_v2" generic="2.0" 
opera tor=" String" authori zedName=" Sir 7 /7£7"> 
<publ isherAssertion> 

<f romKey>S(r7'ng</f romKey> 
<toKey>Str/nff</toKey> 

<keyedReference [tModel Key="Str7'ng"] [keyName="Str77)(7"] keyVal ue="String" /> 
</publ i sherAsserti on> 
[<publ isherAssertion/> ...] 
</publ isherAssertions> 

Obtenir la collection des assertions relationnelles 
Exemple d' utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. assert ion. Publ is her Assert ion; 

import org. uddi 4 j .response.*; 

import org.uddi4j . transport. TransportFactory ; 

import Java .security .Security ; 

import Java .util .Vector ; 

public class UDDIGetPubl isherAssertionsl { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken("user" , "password"); 

PublisherAssertions pas = proxy .get_publisherAssertions( 
at.getAuthInfoString( ) ) ; 

Vector pav = pas.getPublisherAssertionVector( ) ; 
if (pav.size( ) == 0) { 

System. out. printlnC'no publisher assertion(s) found"); 
} 
el se { 

System. out. println(pav. size( )+" publisher assertion(s) found\n"); 

for (int i = 0; i < pav.sizeO; i++) { 

PublisherAssertion pa = (Publ isherAssertion)pav.elementAt(i ) ; 



System. out. println( "fromKey 
System. out. println( "toKey 
System. out. println( "name 
System. out. pri ntl n ( "value 
System. out. pn'ntl n( "\n" ) ; 



"+pa. get FromKey St ring( ) ) ; 
"+pa.getToKeyString( )) ; 
"+pa.getKeyedReference( ) .get Key Name ( ) ) ; 
"+pa.getKeyedReference( ) .getKeyValue( ) ) ; 



proxy.discard_authToken(at.getAuthInfo( ) ) ; 



) 



Ce programme illustre comment obtenir la collection des assertions courantes de Futilisateur user. 
Le resultat presente ci-apres est obtenu apres la mise en ceuvre de 1' exemple utilise pour montrer 
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l'emploi de la fonction add_publ isherAssertions, presentee dans la section suivante : rappelons que 
cet exemple ajoute l'assertion selon laquelle les entites metier nommees Services Web & compagnie 
(cle 5a6aee74-60f2-4093-8988-0f5f858dcb8f) et WS-I organization (cle ee7a7a30-f67c-lld6-b618- 
000629dc0a53) sont liees par une relation nommee Communi ty Member de type peer-peer. Voici le resultat 
renvoye a l'utilisation de ce programme : 

1 publisher assertion(s) found 



f romKey 
toKey 
name 
value 



5a6aee74-60f2-4093-8988-Of5f858dcb8f 
ee7a7a30-f67c-lld6-b618-000629dc0a53 

Community Member 
peer-peer 



La fonction addpubl isherAssertions 

La fonction add_publ isherAssertions a pour objectif de permettre a l'utilisateur d'ajouter une ou 
plusieurs assertions relationnelles a sa collection d'assertions, qui concernent les entites metier qu'il 
controle ou celles avec lesquelles elles sont en relation (voir la remarque « Relations entre entites metier »). 

La definition WSDL de l'operation est la suivante : 

<operation name="add_publ isherAssertions"> 

<input message="tns:add_publ is her Assertions"/) 

<output message="tns:dispositionReport"/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message add_publ isherAssertions est la suivante : 

<add_publ isherAssertions generic="2.0" xmlns="urn:uddi-org:api_v2"> 
<authInfo>5tr7Ajg</authInfo> 
<publisherAssertion> 

<f romKey >String</f romKey > 
<toKey>5tr7'/)g</toKey> 

<keyedReference [tModel Key="String"] [keyUame=" String"] keyValue=" String" /> 
</publ isherAssertion> 
[<publ isherAssertion/> ...] 
</add_publ isherAssertions> 

L element authlnfo contient le jeton d'authentification. 

Les elements publ isherAssertion permettent de specifier une ou plusieurs assertions a ajouter a la 
collection existante. Une assertion est caracterisee par les cles des entites metier associees (elements 
f romKey et toKey) et le sens de la relation exprimee entre ces deux entites via l'element keyedRef erence. 

Les relations suivantes peuvent etre representees : 

• parent-chi Id : les entites metier associees aux elements f romKey et toKey sont liees par une relation 
de dependance ; 

• peer-peer : les entites metier associees aux elements f romKey et toKey sont liees par une relation 
d'egal a egal ; 

• identity : les entites metier associees aux elements f romKey et toKey sont identiques. 
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Cette fonction renvoie un message dispositionReport (voir la section consacree a la fonction 
di scard_authToken) qui donne le resultat de F operation. 

Demander I'ajout d'une ou plusieurs assertions relationnelles 
Exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org. uddi 4 j .data type. Name; 

import org.uddi4j .datatype. assert ion. Publisher Assert ion; 

import org. uddi 4 j .datatype.tmodel .TModel ; 

import org. uddi 4 j . response.*; 

import org.uddi4j . transport. TransportFactory ; 

import org. uddi 4 j .util .KeyedReference; 

import j a va. security .Security ; 

import Java .util .Vector; 

public class UDDIAddPubl isherAssertionsl { 

public static void main(String[] args) throws Exception { 

Le programme recherche tout d'abord les coordonnees des entites metier nommees Services Web & 
compagnie et WS-I organization entre lesquelles une relation va etre exprimee : 

Vector names = new VectorO; 
names .add(new Name( "service Web & compagnie")); 
names. addtnew Name("WS-I organization")); 
BusinessList bl = proxy .find_business( 

names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

System. out. printlntbis. size( )+" business(es) found\n"); 
if (bis.sizeO < 2 | | bis.sizeO > 2) { 

System. out. println( "invalid number of business(es) found"); 

System. exit(0) ; 
} 

Vector biv = bis.getBusinessInfoVectort ) ; 
for (int i =0; i < biv.sizeO; i++) { 

Businesslnfo bi = (BusinessInfo)biv.elementAt(i ) ; 

Sy stem. out. println(bi .getNameString( ) ) ; 

Sy stem. out. println(bi .getBusinessKey( )) ; 

Sy stem. out. println("\n") ; 
} 

Apres avoir localise les entites metier concernees, le programme demande a Foperateur du nceud 
UDDI un jeton d'authentification afin d'etre en mesure de realiser la modification souhaitee, puis 
precede a la creation de 1' assertion relationnelle proprement dite, en creant une relation nommee 
Community Member de type peer-peer, et enfin, demande son ajout dans l'annuaire : 
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AuthToken at = proxy .get_authToken("user" , "password"); 

Publ isherAssertion pa ■ new Publ isherAssertion( ) ; 

pa.setFromKeyString(( ( Business I nfo)bi v.elementAt(O) ) .get Business Key ( ) ; 
pa . setToKeyStringt ( (Business I nfo)biv.elementAt(l) ) . get Business Key ( ) ) ; 
pa.setKeyedReference(new KeyedReference( 

"Community Member", "peer-peer", TModel .RELATIONSHIPS_TMODEL_KEY) ) ; 
DispositionReport dr = proxy .add_publ isherAssertions( 

at.getAuthlnfoStringt ) , pa); 
System. out. printlnC'publ isher assertion added : "+dr.success( ) ) ; 
proxy .discard_authToken(at.getAuthInfo( ) ) ; 



} 

) 



Cet exemple permet de declarer que les entites metier nominees Services Web & compagnie et WS-I 
organization sont liees par une relation nominee Community Member de type peer-peer. Bien entendu, 
il s'agit d'une affirmation unilaterale publiee par l'utilisateur user, responsable de l'entite metier 
Services Web & compagnie, et qui demande a etre confirmee ou infirmee par l'utilisateur qui controle 
l'entite metier WS-I organization. Tant que 1' assertion n'est pas validee, elle demeure invisible aux 
autres utilisateurs de l'annuaire et reste dans l'etat status :toKey_incompl ete comme Findique le resultat 
presente ci-apres. Elle n'est notamment pas accessible par la fonction find_relatedBusinesses. 
Lorsque cette assertion aura ete validee, elle passera au statut status : compl ete. Voici le resultat renvoye 
a l'utilisation de ce programme : 

2 business(es) found 

Services Web & compagnie 

ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

WS-I organization 

ee7a7a30-f67c-lld6-b618-000629dc0a53 

publisher assertion added : true 

L'usage de la fonction get_assertionStatusReport (presentee plus loin dans le chapitre) renvoie le 
statut de cette nouvelle assertion : 

1 assertion(s) found 



f romKey 
toKey 
name 
value 



ba748c9d-73ce-4cd9-85f8-294edddcbbf0 
ee7a7a30-f67c-lld6-b618-000629dc0a53 
Community Member 
peer-peer 



status : toKey_i ncompl ete 

La fonction set_publisherAssertions 

La fonction set_publ i sherAsserti ons permet a l'utilisateur de modifier les assertions de sa collection 
d' assertions existantes (voir la remarque « Relations entre entites metier »). 

La definition WSDL de 1' operation est la suivante : 

<operation name="set_publ isherAssertions"> 

<input message="tns:set_publ i sherAsserti ons "/> 

<output message="tns:publ i sherAsserti ons "/> 

<fault name="error" message="tns :dispositionReport"/> 
</operation> 
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Syntaxe des messages 

La syntaxe du message set_publ i sherAsserti ons est la suivante : 

<set_publ i sherAsserti ons xmlns="urn:uddi-org:api_v2" generic="2.0"> 
<authInfo>5ir7'nc7</authInfo> 
<publ isherAssertion> 

<f romKey>Stf7'ng</f romKey> 
<toKey>Str7A?g</toKey> 

<keyedReference [tModel Key^'Stn'ng"] [keyName^'Strfng"] keyVal ue="String" /> 
</publ i sherAsserti on> 
[<publ isherAssertion/> ...] 
</set_publisherAssertions> 

L'element authlnfo contient le jeton d'authentification. 

Les elements publi sherAsserti on permettent de specifier une ou plusieurs assertions a affecter a la 
collection existante. Une assertion est caracterisee par les cles des entites metier associees (elements 
f romKey et toKey) et le sens de la relation exprimee entre ces deux entites via l'element keyedRef erence. 

Cette fonction renvoie un message publi sherAsserti ons qui contient la nouvelle liste d'assertions 
(voir la section consacree a la fonction get_publ i sherAsserti ons). 

Affecter la collection des assertions relationnelles 
Exemple d' utilisation : 

import org.uddi4j .cl ient.UDDIProxy ; 

import org.uddi4j .datatype. Name; 

import org.uddi4j .datatype. assert ion. Publi sherAsserti on; 

import org.uddi4j . datatype. tmodel .TModel ; 

import org. uddi 4j .response.*; 

import org.uddi4j . transport. TransportFactory ; 

import org.uddi4j .util .KeyedRef erence; 

import Java. security .Security ; 

import Java .util .Vector; 

public class UDDISetPubl isherAssertionsl { 

public static void main(String[] args) throws Exception { 

Le programme recherche tout d'abord les coordonnees des entites metier nommees Services Web & 
compagnie et WS-I organization entre lesquelles une relation va etre etablie : 

Vector names = new VectorO; 

names . add(new Name( "service Web & compagnie")); 

names. addtnew Name("WS-I organization")); 

BusinessList bl = proxy .find_business( 

names, null, null, null, null, null, 0); 
Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
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System. out .println(bis.size( )+" business(es) found\n"); 
if (bis.sizeO < 2 | | bis.sizeO > 2) { 

System. out. printlnC'inval id number of business(es) found"); 

System. exit(O) ; 
} 

Vector biv = bis.getBusinessInfoVector( ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 

System. out. pri ntl n(bi .getNameString( ) ) ; 

System. out . printlntbi .getBusinessKey( )) ; 

System. out .print ln("\n" ) ; 
} 

Apres avoir localise les entites metier concernees, le programme demande a l'operateur du noeud 
UDDI un jeton d'authentification afin d'etre en mesure de realiser la modification souhaitee. II 
precede ensuite a la creation de l'assertion relationnelle proprement dite, de type identity, et enfin 
demande son affectation dans l'annuaire : 

AuthToken at = proxy .get_authToken("user" , "password"); 

Publ isherAssertion pa = new Publ isherAssertiont ) ; 

pa.setFromKeyString(( (Businesslnfo)bi v.elementAt(O) ) .getBusinessKey( )) ; 
pa.setToKeyString( ( (BusinessInfo)biv.elementAt(l) ) . get Business Key ( ) ) ; 
pa.setKeyedReference(new Keyed Reference ( 

"Community Member", "identity", TModel .RELATIONSHIPS_TMODEL_KEY) ) ; 

Publ isherAssertions pas = proxy .set_publisherAssertions( 
at.getAuthlnfoStringt ) , pa); 

Vector pav = pas.getPubl isherAssertionVector( ) ; 
if (pav.size( ) == 0) { 

System. out .printlnC'no publisher assertion(s) found"); 
} 
else { 

System. out .println(pav.size( )+" publisher assertion(s) found\n"); 

for (int i = 0; i < pav.sizeO; i++) { 

pa = (Publ isherAssertion)pav.elementAt(i ) ; 



System. out. pri ntl n( "fromKey 
System. out. println( "toKey 
System. out. println( "name 
System. out. pri ntl n( "value 
System. out. pri ntl n( "\n" ) ; 



"+pa. get FromKey St ring( ) ) ; 
"+pa.getToKeyString( ) ) ; 
"+pa.getKeyedReference( ) . getKeyNamet )) ; 
"+pa.getKeyedReference( ) .getKeyVal ue( ) ) ; 



proxy .discard_authToken(at.getAuth!nfo( ) ) ; 



) 



Ce programme illustre comment affecter la collection des assertions courantes de Futilisateur user. 
Le resultat presente ci-apres est obtenu apres la mise en ceuvre du code de l'exemple utilise pour 
montrer Femploi de la fonction add_publ isherAssertions, presentee precedemment : rappelons que 
cet exemple ajoutait l'assertion selon laquelle les entites metier Services Web & compagnie (cle 
5a6aee74-60f2-4093-8988-0f5f858dcb8f) et WS-I organization (cle ee7a7a30-f67c-lld6-b618- 
000629dc0a53) etaient liees par une relation nommee Community Member, de type peer-peer. Ici, nous 
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avons remplace cette assertion initiale par une nouvelle assertion, toujours de meme nom, mais de 
type identity au lieu de peer-peer. Ail final, la collection contient toujours le meme nombre 
d'elements. Voici le resultat renvoye a Futilisation de ce programme : 

2 business(es) found 

Services Web & compagnie 
5a6aee74-60f2-4093-8988-0f5f858dcb8f 

WS-I organization 
ee7a7a30-f67c-lld6-b618-000629dc0a53 

1 publisher assertion(s) found 



fromKey 
toKey 
name 
val ue 



5a6aee74-60f2-4093-8988-0f5f858dcb8f 
ee7a7a30-f67c-lld6-b618-000629dc0a53 

Community Member 
identity 



II est egalement possible de supprimer d'un seul coup Fintegralite des assertions en cours (validees 
ou en attente de validation) en remplacant le second parametre de la fonction set_publ i sherAsserti ons 
par un vecteur vide. 

La fonction delete_publisherAssertions 

La fonction del ete_publ i sherAsserti ons a pour objectif de permettre a Futilisateur de supprimer une 
ou plusieurs assertions relationnelles de sa collection d' assertions existantes (voir la remarque « Rela- 
tions entre entites metier »). 

La definition WSDL de 1' operation est la suivante : 

<operation name="delete_publ is her Assertions'^ 

<input message="tns: del ete_publi sherAsserti ons "/> 

<output mess age="tns: disposition Report"/) 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 

Syntaxe des messages 

La syntaxe du message del ete_publi sherAsserti ons est la suivante : 

<delete_publ i sherAsserti ons xmlns="urn:uddi-org:api_v2" generic="2.0"> 
<authInfo>Str7'ng</authInfo> 
<publisherAssertion> 
<f romKey>Stn'7?g</f romKey> 
<toKey>String</toKey> 

<keyedReference [tModel Key="S£r77?<7"] [\<.eyUame=" String"] keyVal ue="String" /> 
</publ i sherAsserti on> 
[<publ isherAssertion/> ...] 
</delete_publ i sherAsserti ons> 

L'element authlnfo contient le jeton d'authentification. 

Les elements publ i sherAsserti on permettent de specifier une ou plusieurs assertions a supprimer de la 
collection existante. Une assertion est caracterisee par les cles des entites metier associees (elements 
fromKey et toKey) et le sens de la relation exprimee entre ces deux entites via l'element keyedRef erence. 
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Cette fonction renvoie un message dispositionReport (voir la section consacree a la fonction 
discard_authToken) qui donne le resultat de l'operation. 

Demander la suppression d'une ou plusieurs assertions relationnelles 
Exemple d'utilisation : 

import org.uddi4j .cl i ent.UDDI Proxy ; 

import org.uddi4j .datatype. Name; 

import org.uddi4j .datatype. assert i on. Publ isherAssertion; 

import org.uddi4j . datatype. tmodel .TModel ; 

import org. uddi 4j .response.*; 

import org. uddi 4 j . transport. Transport Factory ; 

import org. uddi 4 j .util .Keyed Reference; 

import Java. security. Security; 

import Java. util .Vector; 

public class UDDIDeletePubl isherAssertionsl { 

public static void main(String[] args) throws Exception { 

Le programme recherche tout d'abord les coordonnees des entites metier Servi ces Web & compagni e 
et WS-I organization entre lesquelles une relation exprimee va etre supprimee : 

Vector names = new VectorO; 
names. add(new Name( "service Web & compagnie" )) ; 
names. add(new Name("WS-I organization")); 
BusinessList bl = proxy .find_business( 
names, null, null, null, null, null, 0); 

Businesslnfos bis = bl .getBusinessInfos( ) ; 
if (bis.sizeO == 0) { 

System. out. printlnC'no business(es) found"); 

System. exit(0) ; 
} 

System. out .println(bis.size( )+" business(es) found\n"); 
if (bis.sizeO < 2 || bis.sizeO > 2) { 

System. out. printlnC'inval id number of business(es) found"); 

System. exit(0) ; 
} 

Vector biv = bis.getBusinessInfoVector( ) ; 
for (int i = 0; i < biv.sizeO; i++) { 

Businesslnfo bi = (Businesslnfo)bi v.elementAtti ) ; 

System. out .pri ntl n(bi . getNameString( ) ) ; 

System. out. println(bi . getBusinessKeyt )) ; 

System. out .pri ntl n("\n" ) ; 
} 

Apres avoir localise les entites metier concernees, le programme demande a l'operateur du nceud 
UDDI un jeton d'authentification afin d'etre en mesure de realiser la modification souhaitee. II 
precede ensuite a la creation de l'assertion relationnelle proprement dite, de type peer-peer, et enfin 
demande sa suppression dans Fannuaire. 
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AuthToken at = proxy .get_authToken("user" , "password"); 

Publ isherAssertion pa = new PublisherAssertion( ) ; 

pa.setFromKeyString( ( (BusinessInfo)biv.elementAt(O) ) .get Business Key ( ) ) ; 
pa.setToKeyString( ( (BusinessInfo)biv.elementAt(l) ) . getBusinessKeyt ) ) ; 
pa.setKeyedReference(new KeyedReference( 

"Community Member", "peer-peer", TModel .RELATIONSHIPS_TMODEL_KEY) ) ; 
DispositionReport dr = proxy .del ete_publ isherAssertionst 

at.getAuthInfoString( ) , pa); 
System. out. printlnt "publ isher assertion deleted : "+dr.success( ) ) ; 
proxy .discard_authToken(at.getAuth!nfo( ) ) ; 



) 



) 



Cet exemple montre comment supprimer Fassertion selon laquelle les entites metier Services Web & 
compagnie et WS-I organization sont liees par une relation de type peer-peer. Bien entendu, il s'agit 
d'une affirmation unilaterale publiee par l'utilisateur user, responsable de l'entite metier Services 
Web & compagnie, qui demande a etre confirmee ou infirmee par l'utilisateur qui controle l'entite 
metier WS-I organization seulement si cette assertion etait auparavant validee, c'est-a-dire visible de 
tous les utilisateurs de l'annuaire. Si tel etait le cas, la relation entre ces deux entites metier n'est plus 
accessible par la fonction f 1 nd_rel atedBusi nesses. En revanche, si cette assertion n'etait pas validee, 
elle disparait totalement comme l'indique le resultat presente ci-apres. Voici le resultat renvoye a 
1' utilisation de ce programme : 

I 2 business(es) found 

Services Web & compagnie 

ba748c9d-73ce-4cd9-85f8-294edddcbbf0 

WS-I organization 

ee7a7a30-f67c-lld6-b618-000629dc0a53 

publisher assertion deleted : true 

L'usage de la fonction get_assertionStatusReport (voir section suivante) renvoie la confirmation 
que cette assertion a bien ete supprimee : 

no assertion(s) found 

La fonction get_assertionStatusReport 

La fonction get_assertionStatusReport permet a l'utilisateur de demander a l'operateur du site le 
statut courant des assertions qui concernent les entites metier qu'il controle, c'est-a-dire de ses propres 
assertions, ainsi que des assertions publiees par les autres utilisateurs liees a ses propres entites metier. 

La definition WSDL de 1' operation est la suivante : 

<operation name="get_asserti onStat us Report "> 

<input message="tns:get_assertionStatusReport"/> 

<output mess age="tns: as sertionSt a tus Report "/> 

<fault name="error" message="tns:dispositionReport"/> 
</operation> 
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Syntaxe des messages 

La syntaxe du message get_assertionStatusReport est la suivante : 

<get_assertionSt a tus Report xmlns="urn:uddi -org:api_v2" generic="2.0"> 

<authInfo>St/"7/7g</authInfo> 

[<completionStatus>Str7'ng , </completionStatus>] 
</get_asserti onStat us Report > 

L'element authlnfo contient le jeton d'authentification. 

L'element optionnel compl eti onStatus permet de filtrer le contenu du rapport renvoye par la fonction : 

• La valeur status: complete permet de ne recuperer que les assertions validees, c'est-a-dire celles 
pour lesquelles les administrateurs UDDI responsables des entites metier concernees sont d' accord 
entre eux. 

• La valeur status : toKey_i ncompl ete permet de ne recuperer que les assertions incompletes, c'est-a- 
dire celles dont les administrateurs UDDI responsables des entites metier referencees (par l'element 
toKey des assertions) n'ont pas publie les assertions correspondantes necessaires a la validation. 

• La valeur status : f romKey_i ncompl ete permet de ne recuperer que les assertions incompletes, c'est-a- 
dire celles dont les administrateurs UDDI responsables des entites metier referencees (par l'element 
f romKey des assertions) n'ont pas publie les assertions correspondantes necessaires a la validation. 

Cette fonction renvoie un message assertionStatusReport qui fournit la liste des assertions : 

<asserti onStatus Report xmlns="urn:uddi-org:api_v2" generic="2.0"> 
<asserti onStatus Item completionStatus="5iT7'ng"> 
<f romKey >String</f romKey > 
<toKey>StrfA?g</toKey> 

<keyedReference [tModel Key="Str7'ng"] [keyName="Str7'ng"] keyValue="5£r7A7g"/> 
<keysOwned> 

<f romKey >Str i ng</ fromKey> 
<toKey>String</toKey> 
</keysOwned> 
</asserti onStatus I tem> 
[<assertionStatusItem/> ...] 
</assertionStatusReport> 

Demander le rapport du statut courant des assertions 
Exemple d'utilisation : 

import org.uddi4j .cl i ent. UDDI Proxy ; 

import org. uddi4j .response.*; 

import org.uddi4j .transport .Transport Factory ; 

import Java. security. Security ; 

import Java. util .Vector; 

public class UDDIGetAssertionStatusReportl { 

public static void main(String[] args) throws Exception { 

AuthToken at = proxy .get_authToken( "user" , "password"); 

AssertionStatusReport asr - 

proxy .get_assertionStatusReport(at.getAuthInfoString( ) , "" ) ; 
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Vector asis = asr.getAssertionStatusItemVector( ) ; 
if (asis.sizeO == 0) { 

System. out. printlnCno assertion(s) found"); 
} 
el se { 

System. out. println(asis. size( )+" assertion(s) found\n"); 
for (int i = 0; i < asis.sizeO; 1++) { 

AssertionStatusItem asi = (AssertionStatusItem)asis.elementAt(i ) ; 
System. out .printlntasi . getFromKeyStringt ) ) ; 
System. out. printlnt asi . getToKeyStringt )) ; 
System. out . pri ntl n( asi .getCompletionStatus( ) ) ; 
System.out.println("\n") ; 



proxy .discard_authToken(at.getAuthInfo( ) ) ; 
} 
} 

Cet exemple permet d'obtenir la situation courante des assertions prealablement posees par Futilisateur 
user sur le site de l'operateur ou eventuellement amrmees par d'autres utilisateurs relatives aux enti- 
res metier controlees par Futilisateur user, quel que soit le statut de ces assertions. Voici le resultat 
renvoye a 1' utilisation de ce programme : 

no assertion(s) found 

II n'existe aucune assertion validee, ni aucune assertion en attente de validation, pour Futilisateur 
user. La section precedente a montre un exemple d' assertion en attente. 



Les modalites d'utilisation des annuaires 

La specification UDDI, outre la description des differentes API, donne egalement quelques conseils 
relatifs a la mise en ceuvre des annuaires, dont les sections qui suivent donnent un apercu. 



Le modele d'invocation 

La specification UDDI decrit un modele d'invocation standard de service Web. Normalement, 1' invo- 
cation d'un service Web s'effectue a partir d'une structure d'informations de type modele de liaison 

(bi ndi ngTempl ate) geree dans un systeme de cache. 

De maniere generate, la demarche de preparation d'un programme a l'invocation d'un service Web est 
realisee via l'utilisation combinee des fonctions de l'API de recherche (qui represented une implemen- 
tation des modeles conceptuels (ou patterns) browse, drill-down et invocation), en voici les etapes : 

1. La premiere etape differe selon le type de service Web recherche : 

- s'il s'agit d'un service particulier propose par un partenaire identifie, il faut rechercher la busi ness 
Entity du partenaire fournisseur du service Web cible. Ce fournisseur peut etre localise, soit 
via un navigateur (browser) d'annuaire UDDI, soit par l'intermediaire d'un outil qui met en 
ceuvre l'API de recherche. 
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- s'il s'agit d'un service banalise propose par de nombreux prestataires, il faut rechercher le 
tModel reference par les implementations des prestataires fournisseurs du service Web cible. 
Ce service type peut etre localise avec les merries outils que l'entite metier. 

2.11 faut ensuite localiser le bindingTemplate recherche qui correspond a 1' implementation du 
service Web que Ton souhaite utiliser, soit a l'interieur de la busi nessEnti ty, soit parmi les services 
metier qui implementent le service type recherche. Ce modele de liaison peut etre localise avec 
les memes outils que l'entite metier ou le service type. 

3. Puis il faut preparer le programme d'acces au service Web selon les specifications contenues dans 
le tModel associe au bindingTempl ate localise (format des messages, types de donnees, etc.). 

4. Enfin, a lieu l'invocation du service Web a partir du bi ndi ngTempl ate prealablement mis en cache. 

La convention d'appel 

La specification UDDI definit egalement une convention d'appel d'un service Web, destinee a prevenir 
les problemes de communication et de disponibilite des services et a maintenir ainsi une certaine 
qualite de service (retry on failure). Cette convention d'appel prevoit les actions suivantes : 

1. Developper et mettre en place un systeme de cache des structures de bi ndi ngTempl ate en runtime. 

2. Lors de l'appel d'un service Web, utiliser le bi ndi ngTempl ate mis en cache lors d'un precedent 
appel. 

3. En cas d'echec, refaire un appel direct a l'annuaire via la fonction get_bi ndi ngTempl ate avec la 
cle bindingKey. 

4. Comparer l'information obtenue avec celle du cache : si elle est differente, refaire l'appel en 
echec, et s'il se passe bien cette fois, remplacerle bindingTemplate en cache par le nouveau. 

Cette convention peut permettre d'eliminer des problemes dus a une modification de la description 
du service Web (comme un changement de l'URL du point d'acces, par exemple) entre le moment ou 
le bindingTemplate a ete mis en cache lors d'un appel precedent et le moment ou un echec a ete 
constate lors du dernier appel du service Web. 

Si l'appel reitere, apres reactualisation du cache, essuie un nouvel echec, il s'agit vraisemblablement 
d'un probleme plus grave de fonctionnement du service Web : serveur arrete ou en surcharge, problemes 
de reseau, temps de latence excessifs, interface du service modifiee sans preavis... Dans ce cas, 
1' application cliente doit remonter une exception au processus appelant ou a l'utilisateur. Dans cette 
configuration, il peut etre interessant d'interfacer le cache avec un systeme de supervision (de 
type Hewlett-Packard OpenView, par exemple) pour remonter une alerte applicative au niveau 
de F administration du reseau. 

La mise en ceuvre de cette convention d'appel permet a un prestataire de services : 

• de router a chaud le flux des communications vers un nouveau serveur ou un systeme de secours, 
via la modification de l'URL fournie dans la donnee accessPoint de la structure d' informations 

bindingTemplate ; 

• de rediriger a chaud le flux des communications vers un nouveau serveur ou un systeme de secours, 
via l'ajout d'une structure de donnees hosti ngRedi rector, laquelle permet la redirection du trafic 
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vers une autre URL fournie dans la donnee accessPoint de la nouvelle structure d' informations 
bindingTemplate pointee ; 

• de faire des sauvegardes de son systeme de production sans interrompre completement son service. 

La mise en ceuvre de cette convention d'appel permet aussi a une application consommatrice de 
services : 

• de maintenir une continuite apparente de fonctionnement face a des interruptions transitoires (mais 
non permanentes) des services qu'elle consomme ; 

• de permuter F operateur d'annuaire car le systeme de gestion du cache se connecte initialement a 
un operateur par defaut, mais en cas de probleme, il peut se connecter a un autre operateur et 
utiliser ainsi la securite offerte par la distribution et la replication de l'annuaire. 

L'utilisation des taxonomies de classification et d'identification 

Les services Web peuvent etre classes en categories et recherches en fonction de certaines informations 
specifiques. Ces informations sont issues de systemes de classification, nommes taxonomies, qui 
permettent de regrouper les services Web en categories plus ou moins finement definies selon une 
semantique propre a la taxonomie mise en ceuvre. 

Ces taxonomies correspondent a des besoins de classification et des semantiques d'ordres divers. 
Elles peuvent correspondre a des necessites : 

• economiques ; 

• administratives ; 

• geographiques ; 

• etc. 

Les taxonomies utilisees fonctionnent generalement par imbrications successives des niveaux de 
classification, un peu a la maniere de poupees russes. II est ainsi possible, par effets de zoom repetes, 
de descendre d'un niveau tres general de classification a un niveau extremement detaille. 

Les taxonomies peuvent etre utilisees pour rechercher des structures de donnees de type business Entity, 
business Service ou tModel. 

De maniere standard, la specification UDDI prevoit l'utilisation possible des taxonomies : 

• (NAICS - 1997) North American Industry Classification System (voir site de reference : http://www 
. census.gov/epcd/www/naics. htmi) ; 

• (UNSPSC - 3. 1 et 7) Universal Standard Products and Services Codes (voir site de reference : http:/ 
/eccma.org/unspsc) ; 

• (GEO) ISO 3166 Geographic Taxonomy (voir site de reference : http://www.iso.ch). 

II est egalement possible d'utiliser d'autres referentiels de classement par identifiants. La specification 
propose par exemple les taxonomies : 

• Dun & Bradstreet D-U-N-S® Number (voir site de reference : http://www.dnb.com) ; 

• Thomas Register (voir site de reference : http://www.thomasregister.com). 
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La correspondance entre WSDL et UDDI 

Un annuaire UDDI a une portee universelle et n'a pas vocation a referencer uniquement des services 
Web accessibles de maniere programmatique. 

En effet, il est possible d'acceder a un busi nessServi ce par plusieurs canaux definis dans les structures 
de donnees de type accessPoint. Un accessPoint precise, par son attribut URLType, le canal utilise par 
le fournisseur du service pour distribuer ce service et atteindre ses clients. Les canaux standards definis 
par la specification sont : 

• mai 1 to : acces par un canal de courrier electronique ; 

• http : acces par un canal HTTP standard ; 

• https : acces par un canal HTTPS securise ; 

• ftp : acces par un canal FTP ; 

• fax : acces par un canal fax ; 

• phone : acces par un canal telephonique ; 

• other : autre canal precise par les donnees de la structure tModel Instancelnfo. 

Par ailleurs, un service Web accessible de maniere programmatique peut s'appuyer surune description 
de type WSDL pour definir Finterface de service a mettre en ceuvre. Mais il ne s'agit pas d'une obli- 
gation : d'autres systemes de norme et de description de services peuvent etre utilises via un annuaire 
UDDI. 

Si Ton decide d'utiliser la specification WSDL, comment combiner le formalisme WSDL et les 
structures de donnees UDDI ? 

La regie generate a appliquer consiste a : 

1. utiliser l'element import de la specification WSDL ; 

2. separer les elements de la description d'un service en « definition d'interface de service » (service 
interface definition) et en « definition d' implementation de service » {service implementation 
definition) ; 

3. decrire dans le document WSDL de definition d'interface de service les elements reutilisables 
communs a une categorie de services metier : les formats de messages, les interfaces abstraites 
(portType) et les liaisons de protocoles (binding) ; 

4. publier le document WSDL de definition d'interface de service dans l'annuaire UDDI ; 

5. publier le(s) document(s) WSDL de definition d' implementation de service, qui reference(nt) le 
document generique de definition d'interface de service dans l'annuaire UDDI. 

Plus precisement, le processus generique d'elaboration d'un service Web est le suivant : 

1. Creation du document de definition d'interface du service : 

- elaboration, par une organisation industrielle ou un groupe d'entreprises, d'un ensemble de 
services types ; 

- transcription de ces services types sous forme d'un ou plusieurs documents de definition d'inter- 
face de service, c'est-a-dire definition des interfaces des services et des liaisons de protocoles 
et publication des documents ; 
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- enregistrement de ces documents sous forme de structures UDDI tModel s : le champ overview 
Doc reference ce document de definition d'interface de service. 

2. Implementation par les developpeurs ou les editeurs de logiciels de ces definitions de standards 
industriels : 

- recuperation de la structure UDDI tModel precedemment definie par un outil de developpement 
compatible UDDI ; 

- generation des proxy-services capables de prendre en charge les definitions d'interfaces et les 
liaisons par un outil de developpement compatible WSDL. 

3. Deploiement de la nouvelle implementation via Fannuaire UDDI (prive ou public) : 

- generation de la structure de donnees businessService correspondant au nouveau service par 
un outil de developpement compatible WSDL et UDDI ; 

- generation d'une structure de donnees bi ndi ngTempl ate pour chaque nceud d'acces au service : 
l'adresse reseau a utiliser est stockee dans une structure de donnees accessPoint et represente 
le document WSDL de definition d' implementation de service ; 

- generation d'une structure de donnees tModel Instancelnfo pour chaque structure tModel prise 
en charge par la structure bi ndi ngTempl ate ; 

- generation des eventuels « descripteurs de deploiement » de services, propres a certaines imple- 
mentations du protocole SOAP : par exemple, le fichier DeployedServices.ds de F implementation 
SOAP de Apache. 

Le document suivant, de la section « Best Practices » du site UDDI, donne un exemple concret de 
mise en ceuvre de cette demarche : Using WSDL in a UDDI Registry, Version 1.08 (voir http://www 
.oasis-open.org/committees/uddi-spec/doc/bp/uddi-spec-tc-bp-using-wsdl-v108-20021 1 10.htm). Elle est egalement 
illustree dans les chapitres 24 (« Architecture dynamique (UDDI) - Implementation Java ») et 25 
(« Architecture dynamique (UDDI) - Implementation .NET ») consacres aux etudes de cas. 

Les implementations d'annuaires UDDI 

Les versions 1.0 et 2.0 de la specification UDDI ont d'ores et deja ete implementees dans un certain 
nombre de produits. Ces implementations se repartissent en deux categories : Fannuaire public et les 
annuaires prives. 

L'annuaire public UBR 

Lannonce de la constitution du projet UDDI, effectuee le 6 septembre 2000, comporte un volet relatif a 
la fourniture d'un annuaire public UBR (UDDI Business Registry) qui constitue une implementation 
de la specification UDDI. 

Cet annuaire est accessible gratuitement via Internet par tout acteur economique. II est lui-meme 
implements comme un service Web, et il est done possible d'y acceder de facon programmatique de 
la meme maniere que n'importe quel autre service Web. 
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L'annonce precise que les premieres implementations de l'annuaire seront developpees et hebergees 
par les entreprises initiatrices de la specification UDDI, c'est-a-dire par les societes Ariba, IBM et 
Microsoft. Ces implementations seront interoperables entre elles et les donnees enregistrees par 
les entreprises utilisatrices seront repliquees entre les differentes implementations. De futures 
implementations interoperables sont egalement prevues. 

En pratique, la premiere version de l'annuaire public est accessible (beta tests) depuis le 16 novembre 
2000 (voir annonce de Ariba : http://www.ariba.com/company/news.cfm?pressid=428&archive=1). Cette meme 
annonce indique que quatre-vingt-quatorze nouvelles entreprises ont adherees a cette initiative 
depuis la constitution initiale du projet : au total cent trente entreprises soutiennent le projet a cette 
date. 



Implementation de Ariba 

De fait, ['implementation a" Ariba n'a jamais ete disponible en production. Le site de test initial de Ariba, accessible a 
I'adresse https://service.ariba.com/UDDIProcessor.aw, n'apparait plus au moment de I'entree en production officielle 
de l'annuaire UDD1 1 .0, le 2 mai 2001 (voir ci-apres). 



La mise en ligne officielle des implementations de Microsoft et IBM est realisee le 2 mai 2001 (voir 
annonce : http://www.uddi.org/uddipr05022001.html). A cette date, le projet est soutenu par une commu- 
naute d'entreprises forte de deux cent soixante membres. Lors de cette communication, l'arrivee de 
Hewlett-Packard en tant qu'operateur de l'annuaire public, aux cotes des operateurs historiques IBM 
et Microsoft, est egalement annoncee. La disponibilite de 1' implementation de ce nouvel operateur 
est prevue pour la fin de l'annee 2001. 

La disponibilite des nouvelles implementations de l'annuaire public qui prennent en charge la 
version 2.0 de la specification UDDI a ete annoncee le 19 decembre 2001 (voir annonce : http://www 
.uddi.org/uddipr1 1 192001 .htm). Ces implementations sont accessibles en beta tests aupres des operateurs 
IBM et Microsoft, qui assurent en parallele le maintien des implementations initiales de la specification 
UDDI 1.0. A ces deux operateurs historiques se sont joints Hewlett-Packard et SAP, afin de proposer 
leur propre implementation initiale directement en version 2.0. A cette date, la communaute 
d'entreprises qui supportent UDDI a depasse les trois cents membres. 

Les implementations disponibles de l'annuaire public 

L'annuaire public est constitue de plusieurs implementations qui se repliquent entre elles. La version 1.0 
de l'annuaire reposait sur les implementations d'IBM et Microsoft et la version 2.0 a ete renforcee 
par l'arrivee de deux nouveaux partenaires. 

Les implementations accessibles 

A l'heure de la redaction de cet ouvrage, il existe done quatre implementations disponibles de 
l'annuaire public : 

• F implementation d'IBM (operateur UBR depuis UDDI 1.0) ; 

• 1' implementation de Microsoft (operateur UBR depuis UDDI 1.0) ; 

• F implementation de NTT Communications (operateur UBR depuis UDDI 2.0) ; 
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• 1' implementation de SAP (operateur UBR depuis UDDI 2.0). 
Ces quatre implementations sont dedoublees en : 

• annuaire public de test (sauf pour NTT Communications) ; 

• annuaire public de production. 



Arrivee de NTT : extension vers I'Asie 

La derniere implementation ouverte est celle de NTT Communications : elle est disponible depuis le 9 octobre 
2002 (voir annonce du lancement : http://www.ntt.com/release_e/news02/0010/1008.html). Celle-ci est hebergee 
par sa filiale NTT/Verio et s'appuie sur une implementation UDDI d'origine IBM WebSphere et DB2 (voir http:// 
www.ntt.com/release_e/news02/0007/0717.htmr). 



Les regies de fonctionnement de ces differentes implementations sont precisees dans les conditions 
d'utilisation de ces sites presentees lors de Fouverture d'un compte d'acces. Les operateurs de 
l'annuaire s'engagent notamment a assurer une disponibilite permanente des sites, la replication des 
informations entre implementations et la sauvegarde des contenus. 

L'ouverture d'un compte d'acces 

L'inscription d'une entreprise et des services offerts par celle-ci passe par l'ouverture prealable d'un 
compte d'acces aupres de Fun des operateurs de l'annuaire. L'inscription s'effectue en ligne, soit a 
partir du site de reference du projet UDDI a Fadresse http://www.uddi.org/register.html, soit directement 
sur le site des differents operateurs de l'annuaire. 

Toutes les operations autres que celles de recherche et de consultation d' informations dans cet annuaire 
necessitent Futilisation d'un compte d'acces. En pratique, ce compte correspond litteralement a celui 
d'un administrateur UDDI. 

Les comptes d'acces ne sont pas eux-memes repliques entre les differentes implementations de 
l'annuaire. lis sont propres a chacun des operateurs de l'annuaire et ne permettent pas de modifier des 
informations relatives a une entite metier geree par un autre operateur. 

Lors de cette phase d'ouverture de compte d'acces, Finterface Web presente les conditions d'utilisation 
du site de Foperateur. Le nouvel utilisateur consultera avec attention les droits et les devoirs qui lui 
incombent du fait de son inscription. 

Des comptes d'acces differences 

Cette convention presente notamment les deux niveaux de compte qui peuvent etre souscrits aupres 
de Foperateur : 

• le compte de premier niveau, qui necessite une identification simple, realisee en ligne : il demande 
generalement le nom de Futilisateur du compte, un numero de telephone, ainsi qu'une adresse de 
courrier electronique valide ; 

• le compte de second niveau, qui necessite un controle de Fidentite de Futilisateur par Foperateur 
du site. 
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Les possibilites associees a ces deux types de comptes correspondent a des champs d' utilisation 
differents : 

• Le compte de premier niveau est plutot destine a etre utilise par des entreprises personnelles 
(professions liberates. . .) ou de petites organisations (PME. . .)■ Ce niveau de compte est limite a la 
gestion de : 

- une structure de type businessEntity au plus ; 

- quatre structures de type businessService au plus ; 

- deux structures de type bindingTemplate au plus par structure businessService ; 

- cent structures de type tModel au plus ; 

- dix structures de type publ isherAssertion au plus. 

• Le compte de second niveau s'adresse aux grandes organisations, aux places de marche ou au 
fournisseurs de services qui offrent des prestations d'enregistrement pour un grand nombre d'entre- 
prises clientes (registrars). Ces comptes ne presentent pas de limitations (sauf eventuellement 
contractuelles) quant au nombre de structures gerees. 

Tout depassement d'une des limites fixees dans un compte se traduit par le retour d'un message 
d'erreur (E_accountLimitExceeded) lors de l'invocation de la fonction fautive de l'API de publication. 

Ces limites s'appliquent aux operateurs de l'annuaire public. La specification UDDI prevoit qu'elles 
peuvent etre differentes, voire levees, dans le cadre d' implementations privees. 

Bien entendu, il est possible de debuter par un compte de premier niveau, puis de passer a un compte 
de second niveau, si besoin est. Une demande expresse en ce sens doit etre formulee aupres de 
l'operateur gestionnaire du compte de premier niveau. 

Les points d'acces aux implementations 

L ensemble des points d'acces aux implementations Web et programmatiques des operateurs de 
l'UBR sont regroupes dans le tableau 12-1. 



Notes relatives aux URL des implementations des operateurs de l'UBR 

^implementation geree par Hewlett-Packard n'est plus accessible depuis la decision de Hewlett-Packard, prise en 

juillet 2002, d'arret partiel de I'activite de la division HP Middleware (voir chapitre 14 « Les plates-formes Java », 

section « L'offre de Hewlett-Packard : Netaction »). 

^implementation d'IBM dispose d'un portail d'acces general Web a I'adresse http://www-3.ibm.com/services/uddi. 

L'obtention d'un compte d'acces aupres de I'implementation de NTT Communications n'est possible qu'en langue 

japonaise. 

La societe SAP a annonce son nouveau statut d'operateur de l'annuaire public, le 4 octobre 2001 (voir annonce 

http://www.sap.com/company/press/press.asp?presslD=629). 
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Tableau 12-1. URL des implementations des operateurs de I'UBR 



Operateur 


Acces 


Annuaire de production 


Annuaire de test 


Hewlett- 
Packard 


NavigateurWeb 


http://uddi.hp.com 


indisponible 


API de recherche 


http://uddi. hp. com/ubr/inquire 


indisponible 


API de publication 


https://uddi.hp.com/ubr/publish 


indisponible 


IBM 


NavigateurWeb 


https://uddi.ibm.com/ubr/registry.html 


https://uddi.ibm.com/testregistry/registry.html 


API de recherche 


http://uddi. ibm. com/ubr/inquiryapi 


http://uddi.ibm.com/testregistry/inquiryapi 


API de publication 


https://uddi.ibm.com/ubr/publishapi 


https://uddi. ibm. com/testregistry/publishapi 


Microsoft 


NavigateurWeb 


http://uddi.microsoft.com 


httpMest. uddi. microsoft, com 


API de recherche 


http://uddi. microsoft, com/inquire 


http://test.uddi.microsoft.com/inquire 


API de publication 


https://uddi.microsoft.com/publish 


https://test.uddi.microsoft.com/publish 


NTT 
Communica- 
tions 


Navigateur Web 


http://www.ntt.com/uddi 


indisponible 


API de recherche 


http:llwww. uddi. ne.jp/ubr/inquiryapi 


indisponible 


API de publication 


httpsJ/www. uddi. ne.jp/ubr/publishapi 


indisponible 


SAP 


NavigateurWeb 


http://uddi.sap.com 


http://udditest.sap.com 


API de recherche 


http://uddi. sap. com/UDDI/api/inquiry 


http://udditest.sap.com/UDDI/api/inquiry 


API de publication 


https://uddi.sap.com/UDDI/api/publish 


https://udditest.sap.com/UDDI/api/publish 



Les annuaires prives 

Les entreprises initiatrices de la specification UDDI (Ariba, IBM et Microsoft) ont prevu des 
l'origine de mettre a disposition des entreprises un annuaire public distribue et replique qui constitue 
1' implementation de reference de la specification. Cet annuaire est done accessible sur Internet par 
toute entreprise ou toute personne physique qui le souhaite. L'utilisation de F annuaire est actuellement 
totalement gratuite, qu'il soit utilise en mode consultation et recherche de services ou en mode 
publication de services. 

Cependant, les entreprises ont besoin de l'apport d'autres implementations d' annuaires qui ne necessitent 
pas d'etre accessibles via Internet. En effet, les applications Web actuelles et a venir peuvent fonc- 
tionner dans le cadre strict de Fentreprise (intranet) ou dans un cercle plus large etendu a des partenaires 
identifies (clients, fournisseurs, prestataires de services, etc.) de la societe (extranet). 

Ces diverses architectures logicielles sont justifiees (et ont des consequences sur la securite des acces, 
les performances reseau, etc.) pour des raisons que nous ne developperons pas ici. Dans ces differents 
domaines, toutes les considerations valables aujourd'hui pour les applications Web classiques restent 
applicables pour les nouveaux logiciels qui tirent profit des services Web. 

Simplement, pour couvrir les besoins des applications intranet et extranet, les entreprises ont besoin 
de disposer d' annuaires UDDI prives qu'elles peuvent controler et administer par leurs propres 
moyens. 
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Les implementations d'UDDI cote serveur 

C'est ainsi qu'une nouvelle generation de serveurs commence a apparaitre sur le marche. Tout d'abord, 
les operateurs des differentes implementations de Fannuaire public de reference proposent un produit 
derive de leur propre infrastructure. Parmi ces produits, on peut citer : 

• IBM WebSphere UDDI Registry, dont la version 1 . 1 . 1 est disponible au moment de la redaction de cet 
ouvrage (voir http://www7b.boulder.ibm.com/wsdd/downloads/UDDIregistry.html). La similitude de l'inter- 
face Web avec celle de Fannuaire public dTBM est frappante. Ce produit, compatible avec la 
specification UDDI 2.0, fonctionne sur le serveur d' applications WebSphere Application Server 4.0.3 
Advanced Edition et la base de donnees DB2 7.2 Fix Pack 5 (et ulterieures) et necessite l'un des 
systemes d' exploitation suivants : 

- Windows 2000 (Service Pack 1 ou ulterieurs) ; 

- Windows NT 4.0 (Service Pack 6a ou ulterieurs) ; 

- Linux (Red Hat 7.1 et SuSE 7.1 : noyaux 2.4). 

• Microsoft .Net Server Family, actuellement disponible en telechargement en version Release 
Candidate 2 (voir http://www.microsoft.com/windows.netserver/default.mspx). Cette famille de serveurs, 
dont le nom de code du projet etait Whistler Server, constitue en fait la prochaine generation de 
serveurs Windows, destinee a prendre la releve de la famille actuelle de serveurs Windows 2000. 
Cette famille est declinee en Web Edition, Standard Edition, Enterprise Edition et Datacenter 
Edition. Ces serveurs prendront en charge de maniere native le framework .Net et les technologies 
associees aux services Web (SOAP, WSDL et UDDI). Les trois dernieres versions prendront en 
charge les Enterprise UDDI Services, implemented en code .NET (voir http://www.microsoft.com/ 
windows, netserver/evaiuation/overview/dotnet/uddi. mspx) . 

• Hewlett-Packard proposait aussi son serveur HP Web Services Registry 2.0 (HP-WSR) (voir http:// 
www.hpmiddleware.com/SalSAPi.dll/SaServletEngine.class/products/hp_web_services/registry/default.jsp), 
compatible UDDI 2.0. Celui-ci integral t egalement la librairie cliente UDDI4J, codeveloppee avec 
IBM (voir la section « Les implementations de UDDI du cote client » ci-apres), ainsi qu'un navi- 
gateur UDDI : le HP Registry Composer. La persistence des donnees etait assuree par les bases de 
donnees Oracle 8.1.6, Microsoft SQL Server 2000 et Hypersonic SQL. Cependant, ce produit fait 
partie de la liste des produits dont la commercialisation est arretee par Hewlett-Packard (voir 
chapitre 14 « Les plates-formes Java », section « HP Middleware : arret partiel de l'activite »). 

Outre ces acteurs majeurs du monde UDDI, il faut egalement noter la presence de nouveaux venus 
specialises dans les technologies des services Web. Voici quelques-unes de ces nouvelles societes : 

• La societe Systinet (anciennement Idoox, voir http://www.systinet.com) propose sa gamme de produits 
WASP (Web Applications and Services Platform) qui se decline en WASP Developer, WASP 
Server et WASP UDDI. Le produit WASP UDDI 4.5 est compatible avec la specification UDDI 2.0 
et implemente une partie des caracteristiques de UDDI 3.0 (voir http://www.systinet.com/products/ 
wasp_uddi/overview). Lannuaire WASP UDDI 4.5 de Systinet est accessible en evaluation en ligne a 
F adresse http://www.systinet.com/uddi/web. 

• La societe The Mind Electric (voir http://www.themindelectric.com) a elabore une plate-forme dediee 
aux services Web nommee Glue (voir http://www.themindelectric.com/glue/index.html). Cette plate-forme, 
declinee en deux versions, Glue Standard et Glue Professional, implemente la specification 
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UDDI 2.0. Les deux versions implemented une couche cliente d'acces a un annuaire UDDI. La 
version Glue Professional implemente un serveur UDDI 2.0, utilisable en developpement, qui 
maintient une persistance des donnees de 1' annuaire au format XML dans le systeme de fichiers de 
la machine qui heberge le serveur. La version Glue Standard implemente egalement un serveur 
UDDI 2.0, mais il est limite a cinq services Web. Ces deux versions seront prochainement 
disponibles en version 3.3. 

• La societe Cape Clear (voir http://www.capeclear.com), creee par des ex-employes de IONA Techno- 
logies, specialiste des anciennes technologies CORBA propose un produit tres oriente Enterprise 
JavaBeans (EJB) et CORBA : Cape Clear 4. Ce produit est une plate-forme complete de gestion de 
services Web qui s'appuie sur un moteur d'execution XML. A ce titre, il integre un serveur UDDI, 
ainsi qu'une librairie d'acces client. 

• Oracle propose la plate-forme Oracle9;AS Release 2 (voir http://www.oracle.com/ip/deploy/ias) qui 
inclut, via le composant Oracle9/AS Containers for J2EE (OC4J), le serveur Oracle9/AS UDDI 
Registry 9.0.3 (voir http://otn.oracle.com/tech/webservices/htdocs/uddi/content.html). Ce serveur UDDI prend 
en charge la specification UDDI 2.0. La persistance des donnees est geree par une base de donnees 
Oracle, comme il se doit. Un client de test est accessible en ligne a http://otn.oracle.com/uddi/ui/ 
searchForm.jsp (Inquiry) et a http://otn.oracle.com/uddi/ui/publishingBase.jsp (Publish). 

• La societe Novell (voir http://www.novell.com), vient tout juste d'annoncer son nouvel annuaire Nsure 
UDDI Server (voir http://www.novell.com/news/press/archive/2002/12/pr02087.html), qui est construit au- 
dessus de sa technologie d' annuaire eDirectory. Ce nouveau produit implemente la specification 
UDDI 2.0. 

• La societe Acumen Advanced Technologies (voir http://www.acumentechnologies.com/site.asp), a ete la 
premiere societe a proposer un serveur UDDI implemente au-dessus d'un annuaire LDAP 3.0 : 
AUDDI-Standard Edition, actuellement disponible en version 1.2. 



Nouvelles implementations ou reutilisation des annuaires LDAP ? 

En matiere de developpement des nouveaux serveurs UDDI, deux courants sont apparus : certains acteurs ont 
realise de nouveaux produits (IBM, Microsoft, etc.) dont la persistance est assuree par des bases de donnees 
relationnelles, d'autres ont considere que les annuaires LDAP etaient suffisamment proches, d'un point de vue 
conceptuel, des annuaires UDDI pour permettre une capitalisation sur les produits LDAP existants (Novell, Acumen, 
etc.). Enfin, certains ont prefere une voie mediane qui s'appuie sur les deux technologies : bases de donnees pour 
le stockage des structures de donnees UDDI et LDAP pour la securisation des acces (Systinet). 
Novell a soumis a I'lETF, en mai 2002, une proposition de schema de representation des types de donnees UDDI 
dans un annuaire LDAP v3.0 (voir LDAP Schema (or UDDI http://www.iett.org/internet-drafts/draft-bergeson-uddi-ldap- 
schema-01.txt). En decembre 2002, Novell a rendu disponible un nouveau serveur Nsure UDDI Server qui exploite 
sa technologie d'annuaire eDirectory. 



Les implementations d'UDDI cote client 

L acces a ces differents serveurs est possible via de nombreuses implementations de la specification 
UDDI cote client. 
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Parmi ces implementations, on peut citer : 

• le SDK UDDI vl.5 for Visual Studio 6 de Microsoft, qui prend en charge Faeces a un annuaire UDDI 1.0 
pour les developpeurs qui utilisent l'ancienne version de Visual Studio (voir http://msdn.microsoft.com 
/downloads/default.asp?URL=/downloads/sample.asp?url=/MSDN-FILES/027/001/893/msdncompositedoc.xmt) ; 

• le SDK UDDI .NET vl.76 beta de Microsoft, quinecessiteleframework.NET l.Oversion 1.0.3705 
(inclus dans Visual Studio .NET final release) et prend en charge UDDI 1.0 (voir http://msdn. microsoft 
.com/downloads/default.asp?url=/downloads/sample.asp?url=/MSDN-FILES/027/001/814/msdncompositedoc.xml) ; 

• le SDK UDDI .NET v2.0 beta 1 de Microsoft, qui necessite le framework .NET 1 .0 version 1 .0.3705 
(inclus dans Visual Studio .NET final release) et prend en charge UDDI 2.0 (voir http://msdn. microsoft 
.com/downloads/default.asp?url=/downloads/sample.asp?url=/MSDN-FILES/027/001/874/msdncompositedoc.xml) ; 

• l'Office XP Web Services Toolkit 2.0 de Microsoft, une boite a outils qui apporte Faeces aux 
annuaires UDDI a la suite bureautique de Windows XP, directement sous Fediteur VBA (voir http://www 
.microsoft.com/office/developer/webservices/default.asp) ; 

• le paquetage UDDI4J dTBM, qui est utilise pour tous les exemples presentes dans ce chapitre, est 
disponible sur le site dTBM developerWorks dedie aux projets Open Source, dans la section 
consacree aux projets Open Source sous licence IBM Public License, a l'adresse http://oss.software 
.ibm.com/developerworks/projects/uddi4j. II est egalement inclus dans divers produits dedies aux 
services Web, ainsi que dans les environnements de developpement WebSphere Studio Application 
Developer (dedie aux developpeurs d' applications Java) et WebSphere Studio Site Developer 
(dedie aux developpeurs de sites et d' applications Web) ; 

• l'environnement d' execution IBM WSTK (Web Services Toolkit), qui fait aussi appel au paquetage 
UDDI4J, est disponible sur le site dTBM alphaWorks dedie aux technologies emergentes a 
l'adresse http://www.alphaworks.ibm.com/tech/webservicestoolkit, il est actuellement telechargeable en version 3.3. 

A cote de ces « poids lourds » de la specification UDDI, il faut egalement noter d'autres implementations 
disponibles separement ou incluses dans des produits : 

• le paquetage Java Open Source jUDDI (voir http://www.juddi.org), initie a Forigine par des membres 
de la societe Bowstreet, qui implemente la version 2.0 d'UDDI ; 

• la societe Cape Clear (voir http://www.capeclear.com), qui a travers son produit Cape Clear 4, offre 
egalement une implementation cliente d'UDDI (« UDDIDirect ») ; 

• la societe Sun Microsystems (voir http://java.sun.com/xml/downloads/jaxr.html), qui a travers son 
implementation Java API for XML Registries (JAXR) vl.0_02, offre egalement une API cliente 
UDDI, cette implementation est disponible via la distribution Java Web Services Developer Pack 
ou Java XML Pack ; 

• la societe Inspire It (voir http://www.inspireit.biz), qui propose une implementation cliente compatible 
UDDI 3.0 (voir http://www.inspireit.biz/products/products.jsp) : UDDI Client 1.0. 

Les annuaires de tests 

Le developpement des nouvelles generations d' applications Web fondees sur la mise en ceuvre de 
services necessite egalement de disposer d'annuaires dedies aux phases de realisation et de tests du 
cycle de developpement de cette nouvelle categorie d' applications. 
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Comme nous Favons vu precedemment, les initiateurs de la specification UDDI ont prevu de dedoubler 
leurs implementations respectives de Fannuaire public UDDI afin de fournir F infrastructure necessaire 
aux architectes et aux developpeurs pour leur permettre : 

• d'e valuer les premiers outils de developpement disponibles (au stade alpha ou beta de developpement) ; 

• d'evaluer les plates-formes d' implementation de Fannuaire ; 

• de realiser des developpements specifiques dans le cadre d'une cellule de veille technologique ; 

• de realiser des developpements initiaux destines a passer en production (projets pilotes). 

Ces plates-formes de tests sont accessibles avec un compte d'acces comme pour Fannuaire de 
production. Ce compte d'acces peut etre le meme que celui qui est utilise en production, mais pour 
des raisons pratiques evidentes, il est preferable de les dedoubler. 

A la difference des annuaires de production, ces annuaires de tests ne sont pas repliques entre eux. 

A l'instar de Fannuaire public qui offre des zones de production et de test, les infrastructures 
d' annuaires prives, etudiees precedemment, doivent egalement pouvoir etre dedoublees en zone de 
production et zone de test (separation des environnements de production et de developpement). 

Les nouveautes introduites par UDDI 3.0 

L' organisation UDDI avait prevu de delivrer une troisieme version de la specification en decembre 
2001, puis de soumettre cette ultime version de la specification a un organisme de normalisation 
encore a determiner (voir support UDDI Roadmap de la presentation du projet du 6 septembre 2000 : 

http://www. uddi. org/pubs/UDDI_Overview_Presentation.ppt) . 

Ce calendrier initial n'a pas ete respecte, le communique de presse relatif a la mise en ligne des 
implementations de la specification UDDI 2.0 en beta tests Fa confirme en annoncant la sortie 
de la proposition publique (draft) de la specification UDDI 3.0 pour 2002 (voir http://www.uddi.org/ 
uddipr11192001.htm). 

L'annonce effective de la publication de la specification UDDI 3.0 est finale ment intervenue le 
30 juillet 2002 (voir annonce : http://www.uddi.org/news/uddi_news_07_30_02.html). Cette meme annonce a 
egalement ete F occasion de communiquer le nom de F organisme de standardisation choisi in fine par 
la communaute UDDI pour prendre le controle de F evolution de la specification UDDI : ce choix 
s'est finalement porte sur FOASIS. 

Cette annonce a ete immediatement suivie, le 6 aout 2002, par la publication de la formation du 
comite technique OASIS UDDI Specification Technical Committee (UDDI-spec), charge de poursuivre 
les travaux de la communaute UDDI selon les procedures propres a FOASIS (voir http://lists.oasis- 
open.org/archives/tc-announce/200208/msg00002.html). Le site d'accueil de ce comite est accessible a http:// 
www. oasis-open, org/committees/uddi-spec. 

Lors de sa premiere reunion, le comite technique a decide, le 13 septembre 2002, de proposer la 
candidature de la specification UDDI 2.0 au statut de standard OASIS. La version 3.0 n'a pas ete 
retenue en raison du manque de recul des membres du comite par rapport a cette derniere version. 
Cette version n'est pas encore implemented, notamment par les membres de FUBR, et quelques 
implementations privees partielles commencent seulement a apparaitre (Systinet WASP UDDI 4.5, 
par exemple). 
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La liste des fonctionnalites d'UDDI 3.0 est publiee dans le document UDDI Version 3 Features List 
(voir http://uddi.org/pubs/uddi_v3_features.htm). Parmi celles-ci, nous pouvons relever : 

• le maintien des cles entre annuaires : partage de donnees entre annuaires (notions de topologies 
d'annuaires, d' annuaires racines et affilies), transformation des cles au format UUID en format 
URI selon un schema identique a celui des noms DNS ; 

• la prise en charge de la signature numerique ; 

• F introduction de la notion de politique (ou charte) de gestion d'un annuaire (policy) ; 

• des ameliorations du modele d'information : categorisation possible des modeles de liaison, 
introduction d'une nouvelle structure de donnees operationnelles (operational Info) qui contient 
des metadonnees de gestion des autres entites, utilisation possible de plusieurs documents overview 
Doc au lieu d'un seul, prise en charge de categorisations plus complexes, extension du modele d'infor- 
mation UDDI possible via le mecanisme de derivation d'XML Schema, amelioration des schemas 
UDDI, amelioration de la prise en charge de l'internationalisation et des langues, modification du 
fonctionnement des points d'acces et du support des descriptions WSDL ; 

• des capacites de recherche etendues : requetes imbriquees, nouveaux qualificateurs de recherche, 
alignement de F usage du caractere joker sur la norme SQL, gestion de pagination pour les grandes 
listes (chunking) ; 

• 1' introduction d'une API de notification des changements intervenus dans un annuaire ; 

• des ameliorations dans la gestion d' annuaire : introduction d' une API de transfert de la conservation 
et de la propriete des informations entre nceuds, amelioration du schema et de 1' API de replication, 
amelioration de la validation de taxonomies externes. 

La version 3.0 de la specification UDDI est materialisee par revolution des documents de reference 
publies lors de la mise en ligne de la version 2.0. 

Les documents de la version 2.0 : 

• UDDI Version 2.04 API Specification (voir http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf) ; 

• UDDI Version 2.03 Data Structure Reference (voir http://uddi.org/pubs/DataStructure-V2.03-Published- 
20020719.pdf) ; 

• UDDI Version 2.03 Replication Specification (voir http://uddi.org/pubs/Repiication-V2.03-Published- 
20020719.pdf) ; 

• UDDI Version 2.01 Operator's Specification (voir http://uddi.org/pubs/Operators-V2.01-Published-20020719.pdf) ; 

ont ete remplaces par l'unique document UDDI Version 3.0 Published Specification, 19 July 2002 
(voir http://uddi.org/pubs/uddi-v3.00-published-20020719.pdf). 

Conclusion 

L evolution de la specification UDDI est maintenant passee sous le controle de l'OASIS. La specifi- 
cation UDDI 2.0 est sur le point de devenir un standard OASIS. 

La reunion pleniere (Face-to-face Meeting) du comite technique OASIS qui s'est tenue dans les 
locaux de SAP America a Philadelphie, les 11 et 12 novembre 2002, a ete l'occasion de dresser la 
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liste des themes qui devront etre abordes dans Foptique de la publication de la future version 4.0 de 
la specification UDDI (voir la section 1.12 « Future spec, content Items » des minutes de la reunion : 
http://lists.oasis-open.org/archives/uddi-spec/200211/doc00008.doc). Cette liste est consequente et montre bien 
le role tres important que la specification UDDI sera amende a jouer dans le contexte de la pile des 
protocoles de base des services Web. 
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Principes de mise en oeuvre 



Quels sont les principes qui doivent guider Futilisateur dans la mise en oeuvre d'une architecture a 
base de services Web ? Quelles sont les technologies disponibles ? Quelles plates-formes de deploie- 
ment faut-il adopter ? Quels environnements de developpement faut-il utiliser ? Quels sont les change- 
ments introduits dans les architectures de systemes d' information ? Comment le principe de l'inter- 
operabilite entre plates-formes est-il acquis ? Quelles sont les difficultes qui subsistent ? 

Autant de questions auxquelles le present chapitre et les suivants vont tenter d'apporter des reponses 
et permettre ainsi d'apprehender les diverses facettes introduites par F apparition de ces nouvelles 
technologies. 

Les plates-formes 

La premiere remarque que nous pouvons faire a propos de la technologie des services Web consiste a 
preciser qu'il ne s'agit pas d'une technologie « revolutionnaire », mais plutot que nous nous trouvons 
en presence d'une technologie « evolutionnaire », en ce sens qu'elle n'est pas destinee a remplacer 
une ou plusieurs technologies existantes, mais plutot a cohabiter et coexister avec les elements 
preexistants du patrimoine applicatif des entreprises. 

Certes, il devient possible de definir et de mettre au point de nouvelles architectures de services 
exclusivement fondees sur les differentes composantes technologiques introduites par les services 
Web (Web Services Generation II), mais dans la pratique, le premier besoin des entreprises reste et 
restera de proteger l'investissement consequent deploye au fil des annees, voire des decennies pour 
les plus grandes d' entre elles. De ce fait, ce que recherchent ces entreprises avant tout, ce sont les 
briques technologiques qui leur permettent de developper de nouvelles extensions, souvent vitales, 
de leurs systemes d' information, capables de fonctionner harmonieusement avec les briques ante- 
rieures, les fameux systemes patrimoniaux (legacy systems). Elles desirent par ailleurs communiquer 
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plus facilement avec les systemes d'information de leurs partenaires : clients, fournisseurs, sous- 
traitants, etc. 

Cette activite d' « urbanisation des systemes d'information » s'est trouvee ralentie ces dernieres 
annees du fait de 1' absence de technologies capables de re lever le defi de la connexion des systemes 
d'information entre entites economiques heterogenes a travers Internet. Bien sur, une premiere vague 
de technologies, essentiellement proprietaries et souvent tres couteuses, a permis d' assurer la prise en 
compte d'une partie des besoins. 

Cependant, l'arrivee d'XML a provoque un declic. En effet, outre l'aspect premier de standardisation 
de documents, la possibilite d'utiliser XML pour communiquer des meta-descriptions (de donnees, 
de documents, de procedures...) a ouvert des horizons nouveaux. En fait, des technologies plus 
anciennes telles que l'EDI (Electronic Data Interchange) et l'EAI (Enterprise Application Integration) 
sont appelees a etre remplacees par une nouvelle vague technologique que certains nomment deja IAI 
(Internet Application Integration). 

A ce jour, le tres grand nombre d' implementations du protocole de transport SOAP, qui, rappelons-le 
encore, n'est pas le seul protocole de transport utilisable du point de vue de la specification WSDL, 
rend le nombre de plates-formes virtuellement utilisables en tant qu'environnements d'execution de 
services Web quasiment illimite. Un petit detour par le site de ressources SoapWare.org, qui recense les 
implementations SOAP existantes (voir http://www.soapware.0rg/directory/4/implementations), suffit pour se 
rendre a 1' evidence. Cependant, la necessite de rationaliser le pare applicatif des entreprises, deja en 
cours, conduira inevitablement a une montee en puissance d'un nombre limite de plates-formes. 

La plupart des analystes s'accordent a penser que deux plates-formes s'arrogeront la plus grosse part 
du marche dans ce domaine : 

• la plate-forme J2EE de Sun et de la communaute JCP, desormais mature ; 

• la plate-forme .NET de Microsoft, encore jeune, mais deja tres prometteuse. 



Deux etudes recentes illustrent cette evolution probable. L'etude North American Developer Survey, realisee 
aupres de huit cents developpeurs canadiens et americains, en mars/avril 2002, par Evans Data Corporation 
(http://www.evansdata.com), montre que 28 % d'entre eux utilisent la plate-forme .NET contre 27 % pour la plate- 
forme J2EE. Par ailleurs, pres de la moitie d'entre eux prevoient d'utiliser un melange d'applications Java et .NET 
dans leurs societes respectives. L'etude Microsoft Steps Into the Ring - Application Delivery Strategies du META 
Group (http://www.metagroup.com), publiee en mars 2002, tend a montrer que la part de marche de la plate-forme 
.NET atteindrait 30 %, tandis que celle de la plate-forme J2EE se stabiliserait a hauteur de 40 % en 2004. La stabi- 
lisation entre ces deux plates-formes interviendrait en 2005/2006. Cette evolution des parts de marche serait en 
grande partie due a la demande en matiere de services Web. 



.NET 



Cette plate-forme technologique constitue le resultat d'un intense effort de specification de ses compo- 
sants de base au sein de l'ECMA (European Computer Manufacturers Association). Cette activite, 
menee dans le cadre des comites techniques de l'ECMA, a abouti a la publication, en decembre 2001 : 

• du langage C# (standard ECMA-334), a partir de soumissions de Hewlett-Packard, Intel et 
Microsoft ; 
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de 1' infrastructure commune de langages CLI (Common Language Infrastructure), standard 
ECMA-335. 



Comite technique 39 (TC39) de I'ECMA 

Les societes membres du comite technique 39 (TC39), en charge de la standardisation de ces elements, etaient : 
Alcatel, Callscan, Compaq, Hewlett-Packard, IBM, Microsoft, Netscape et Sun Microsystems. D'autres societes ont 
egalement contribue a cette standardisation, telles Fujitsu Software, Hewlett-Packard, Intel Corporation, ISE, 
Monash University, OpenWave et Plum Hall. 



Ces deux standards ont ete soumis au comite ISO/IEC JTC 1 (comite technique des technologies de 
rinformation) et sont a l'etat de projets de norme : 

• comite JTC 1/SC 22 - Specification du langage C# : projet ISO/IEC DIS 23270 (voir http:// 
wwwJso.org/iso/fr/stdsdevelopment/techprog/workprog/TechnicalProgrammeProjectDetailPage.TechnicalProgram- 
meProjectDetail?csnumber=36768) ; 

• comite JTC 1/SC 22 - Infrastructure commune de langages : projet ISO/IEC DIS 23271 (voir 
http://www.iso.org/iso/fr/stdsdevelopment/techprog/workprog/TechnicalProgrammeProjectDetailPage.TechnicaiPro- 
grammeProjectDetail?csnumber=36769). 

Ces standards sont sur le point de devenir des normes ISO (etape publication atteinte le 27 fevrier 
2003). Le site de Microsoft regroupe les references associees a ce processus de normalisation, ainsi 
que les liens des sites miroirs des partenaires engages dans le processus (voir http://msdn.microsoft.com/ 
net/ecma/default.asp). 

Microsoft et Corel ont co-developpe une implementation des constituants de la plate-forme .NET 
dont les sources sont maintenant telechargeables, sous le regime de la licence source partagee 
(Microsoft shared source license : voir http://www.microsoft.com/resources/sharedsource/default.mspx). Cette 
implementation (nom de code « Rotor ») peut etre utilisee a des fins educatives et de recherche. Elle 
est operationnelle sous les systemes d' exploitation Windows XP, FreeBSD et Mac OS X (voir http:// 
msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/MSDN-FILES/027/002/097/msdncom- 
positedoc.xml). 

D'autres versions portees de Rotor vont fatalement apparaitre dans les prochains mois. Deja, un 
premier portage vers Linux Red Hat 7.2 et 7.3 est annonce par Shaun Bangay, professeur associe au 
departement des sciences de Funiversite de Rhodes en Afrique du Sud. Le code source de ce portage 
est actuellement heberge sur la plate-forme d'O'Reilly Network (voir http://www.oreillynet.com/cs/weblog/ 
view/wlg/1602). 

A partir de ce socle standardise, nomme framework .NET, Microsoft a construit une offre techno- 
logique apte a prendre en charge et a permettre le developpement et le deploiement de services Web. 
Toute la gamme de produits existants est en cours d' evolution afin de prendre en compte l'arrivee des 
technologies issues de XML et plus particulierement les services Web et le framework .NET Cette 
partie de l'offre de Microsoft restera bien entendu la partie commerciale sur laquelle la societe appuie 
sa croissance. 

Pour completer le tableau, il faut egalement citer les initiatives suscitees par la presente standardisa- 
tion ECMA et la future normalisation ISO dans le monde de FOpen Source. En effet, ces caracteris- 
tiques n'ont pas manque d'attirer l'attention de certains acteurs dans ce domaine. Des projets tels que 
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DotGNU (http://dotgnu.org) ou Mono (http://www.go-mono.com), lances par la societe Ximian (http:// 
www.ximian.com), visent a s'approprier les elements importants de la plate-forme .NET et a produire 
des implementations susceptibles de fonctionner sur des configurations autres que Windows, comme 
Linux, FreeBSD ou Mac OS X, par exemple. 



J2EE 



Le developpement de la plate-forme Java/J2EE, pilote par Sun Microsystems au travers de la 
communaute JCP (Java Community Process), est maintenant parvenu a un stade de maturite satisfai- 
sant, preuve en est l'espacement de plus en plus important entre les versions majeures de la plate- 
forme. Cette plate-forme, dont le point d'entree des ressources est situe a http://java.sun.com/j2ee, est 
maintenant utilisee par une tres grande population de developpeurs. 

Le salon JavaOne 2001 avait ete l'occasion pour Sun Microsystems d'annoncer que la prochaine 
version de la plate-forme J2EE (1.4) integrerait les implementations des technologies destinees au 
support des services Web. Malheureusement, il semble que les developpements de cette plate-forme 
soient plus lents que prevu, comme le montre la tres recente disponibilite des paquetages (packages) 
intermediaries JAX Pack et Java Web Services Development Pack (WSDP), et il est maintenant 
certain que la nouvelle plate-forme J2EE 1.4 ne sera pas disponible avant Fete 2003. La 
version 1 .4 beta de ce SDK J2EE est cependant disponible depuis le 6 novembre 2002 (voir http:// 
Java. sun. com/j2ee/download. htmi#sdk) . 

II semble que le retard initial soit du au fait que Sun, en depit du fait que le langage XML ait ete co- 
invente par Fun de ses ingenieurs, Jon Bosak, n'ait pas cru au succes et au potentiel de cette nouvelle 
technologie et ait plutot oriente ses efforts vers la technologie EJB. Ceci s'est traduit dans les faits par 
une arrivee tardive d'analyseurs syntaxiques XML et XSL dans Foffre de Sun, bien apres celle 
dTBM et d'autres acteurs dans ce domaine. 

Dans la pratique, le support de JAXP dans Foffre de Sun n'est intervenu qu'a partir de la version 
J2EE 1.3 (voir roadmap publiee lors du salon JavaOne 2001 : http://java.sun.com/javaone/javaone2001/ 
pdfsZ2155.pdf) et de la version J2SE 1 .4 sortie au debut de F annee 2002. Le support de ces technologies 
dans J2SE 1 .4 est realise via le nouveau mecanisme des standards endosses (endorsed standards) : 
voir - http://java.sun.eom/j2se/1.4/docs/guide/standards. La prochaine version de J2SE (version 1.5, nom de 
code « Tiger »), prevue pour le deuxieme semestre de F annee 2003, devrait integrer une mise a jour 
de F API JAXP ainsi que F apparition des API JAXB et JAX-RPC (voir - roadmap publiee lors du salon 
JavaOne 2002 : http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1756.pdf). 

En ce qui concerne la plate-forme J2EE 1.4, le salon JavaOne 2002 n'a pas donne d'indications 
en termes de date de disponibilite (voir roadmap publiee lors du salon JavaOne 2002 : http:// 
servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/3243.pdf). De la lecture de ce docu- 
ment, il en ressort une information tres claire : e'est le rythme d'avancement du paquetage Java Web 
Services Development Pack (WSDP) qui determinera la date de disponibilite de J2EE 1 .4. En atten- 
dant, les developpeurs et editeurs de produits sont invites a patienter en incorporant le nouveau paque- 
tage dans leurs environnements de developpement et d'execution existants si le besoin s'en fait sentir. 

Le resultat, de ce qu'il faut bien qualifier de « retard a Fallumage » du moteur XML et technologies 
derivees chez Sun, ne s'est pas fait attendre et s'est manifeste par l'apparition de diverses implemen- 
tations Java plus ou moins proprietaries des differentes specifications qui regissent le monde XML, et 
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plus recemment, les evolutions liees a 1' apparition des services Web. Ces nouvelles implementations 
des specifications SOAP, WSDL et UDDI ont ete le fait de grandes societes comme IBM et Hewlett- 
Packard par exemple, de communautes Open Source comme Apache et de nombreuses start-ups 
comme The Mind Electric, Systinet, Cape Clear pour n'en citer que quelques-unes. 

La consequence de la situation ainsi creee est que Fentreprise qui s'est deja investie dans les techno- 
logies Java/J2EE et qui souhaite poursuivre dans les nouvelles technologies de services Web est 
contrainte, soit de differer son investissement, soit de choisir parmi les differentes implementations 
disponibles a ce jour, mais susceptibles de disparaitre ou d'etre rachetees par d'autres acteurs. 

C'est ainsi, par exemple, que les deux premiers serveurs d' applications J2EE capables de prendre en 
charge des services Web, c'est-a-dire WebSphere 4.0 et WebLogic 6.1,ontdufaire appelades imple- 
mentations de composants developpes par eux-memes ou disponibles aupres de la communaute 
Open Source. WebSphere s'appuie par exemple sur les analyseurs syntaxiques Xerces et Xalan 
d' Apache reconditionnes par IBM. WebLogic s'appuie egalement sur l'analyseur syntaxique Xerces. 

Fort heureusement, les implementations disponibles actuellement sont deja efficaces et operationnel- 
les. Par exemple, les produits Glue de The Mind Electric ou CapeConnect de Cape Clear sont capa- 
bles de fonctionner comme des plates-formes autonomes ou bien de s'integrer dans des serveurs 
J2EE de maniere tres simple, que ceux-ci soient tres repandus comme WebLogic et WebSphere ou 
moins connus. En outre, ils montrent de tres bonnes performances en execution. 

Le choix dune plate-forme 

Le choix d'une plate-forme est dicte par la prise en compte de nombreuses considerations liees a la 
presence ou non d'un pare applicatif preexistant, de choix d' architectures deja effectues ou non, de 
la culture technologique de Fentreprise, etc. 

Une entreprise deja fortement engagee dans l'une ou l'autre de ces technologies poursuivra vraisem- 
blablement son evolution dans la meme direction. A l'inverse, une societe pas encore tres engagee 
pourra etre amenee a effectuer des choix. Pour autant, contrairement a la situation qui prevalait dans 
le passe, ce choix n'est plus aussi cornelien. 

Primaute du concept de service 

En effet, contrairement a ce que nous avons connu ces dernieres annees, les conflits « ideologiques » 
entre les tenants de 1' architecture COM/DCOM et ceux de F architecture CORBA d'abord, et Java/ 
J2EE ensuite, n'interessent plus grand monde. 

L'arrivee des nouvelles technologies de services Web permet de s'abstraire des particularites et autres 
incompatibilites entre ces deux (ou trois) anciens mondes. Le chapitre 2 (« Le contrat de service ») 
decrit parfaitement la nouvelle situation : le concept de service est passe au premier plan. Le concept 
de composant logiciel, sous-tendu par les architectures COM/DCOM, CORBA ou J2EE, se trouve 
relegue au second plan et reduit a un role dependant, banalise et interchangeable. 

II resulte de ce changement que les technologies de production de composants logiciels ne consti- 
tuent plus des elements structurants en matiere d' architecture de systemes d'information : Futilisa- 
tion de l'une ou l'autre de ces technologies n'est plus qu'un choix d' implementation effectue par le 
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responsable de F implementation d'un nouveau service. II est d'ailleurs symptomatique de constater 
que les editeurs specialises dans les logiciels de support aux services Web considerent les applica- 
tions issues des technologies COM/DCOM, CORBA ou J2EE comme des systemes patrimoniaux 
d'entreprise (legacy systems). 

Interoperability plutot que portability 

Du coup, ce qui etait extremement couteux autrefois, via l'utilisation de ponts CORBA/COM, puis 
Java/COM, relativement complexes et difficiles a mettre en ceuvre, devient aujourd'hui beaucoup 
plus simple a realiser. Certes, il existe encore des difficultes a surmonter (voir a ce sujet le chapitre 17 
consacre au defi de l'interoperabilite) et des evolutions a realiser, notamment dans les domaines de la 
gestion de processus metier complets, des transactions et de la prise en compte des imperatifs de 
securite. Le support complet du concept de service n'est done pas encore acquis. 

Malgre tout, nous percevons peu a peu le fait que F edifice commence a etre solide, qu'apres les 
specifications initiales, les premieres normes sont sur le point d'etre publiees (W3C, OASIS) et que, 
les crises des nouvelles technologies aidant, le mouvement va bien dans le sens d'une couverture des 
besoins reels des entreprises, et non plus dans le sens d'une protection des pares installes (materiels 
et logiciels), des positions acquises ou a acquerir et au final d'un manque de concurrence et d'un 
immobilisme latent. 

En effet, les evolutions introduites par les technologies de production de composants logiciels ont 
permis aux entreprises de se degager partiellement de F emprise des editeurs de logiciels et des fabri- 
cants de materiels, notamment du fait de Faccroissement de \a portabilite des logiciels. Cependant, cette 
portabilite n'est pas encore totale (difficultes de transfert et d' installation d'une application EJB d'un 
serveur d' applications J2EE vers un autre, par exemple) et peut etre remise en cause a tout instant. 

Malheureusement, il apparait clairement aujourd'hui que la seule prise en compte de cette caracte- 
ristique de portabilite est insuffisante pour couvrir les besoins des entreprises et les rendre plus inde- 
pendantes de leurs fournisseurs. A la volonte de rationalisation des configurations materielles et logi- 
cielles, voulue par les responsables informatique des societes, s'opposent les mouvements de 
concentration et de fusion des entreprises. De ce fait, la nature heterogene des logiciels (bases de 
donnees, langages de programmation, mode les de composants...) et des materiels (pares installes, 
systemes d' exploitation, etc.) a Finterieur des entreprises impose de trouver d'autres reponses. De 
meme, les besoins d'integration de processus metier entre entreprises augmentent, et la probabilite que 
les configurations materielles et logicielles des entreprises concernees soient homogenes reste faible. 

La reponse qui se dessine aujourd'hui consiste a accepter cette situation et a favoriser plutot V intero- 
perabilite des elements constitutifs du patrimoine logiciel et materiel existant de Fentreprise. A quoi 
sert-il d'engloutir des budgets colossaux dans un projet de refonte globale du systeme d' information, 
refonte qui sera a reprendre au premier changement dans la situation de Fentreprise (absorption, 
fusion, etc.) ? Quel sera le retour sur investissement d'un tel projet ? 

L'interoperabilite, plus que la portabilite : tel est le credo actuel des entreprises et des editeurs de logi- 
ciels. Interoperabilite dans Fentreprise, mais aussi entre entreprises via Internet, interoperabilite entre 
langages de programmation (plus de programmes Java qui ne savent dialoguer qu'avec d'autres 
programmes Java), interoperabilite entre modeles de composants (plus de composants COM qui ne 
savent interagir qu'avec d'autres composants COM), interoperabilite entre systemes d'exploitation, etc. 
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Support du concept de service 

Les technologies de services Web favorisent done cette caracteristique d'interoperabilite entre imple- 
mentations (logicielles et materielles). La portabilite n'est plus un critere structurant dans l'architec- 
ture du systeme d' information, mais un choix d'implementation. Le concepteur d'un service peut 
choisir de mettre au point une implementation de service portable ou non. Du point de vue des clients 
de ce futur service, cela n'a aucune espece d'importance. En revanche, ce qui est primordial dans une 
telle architecture, est que cette implementation respecte totalement les specifications et les normes 
qui regissent les services Web : seul le respect de ces regies garantit l'interoperabilite. D'ou l'impor- 
tance accordee a cette question par les principaux acteurs de ce domaine et la creation d'un orga- 
nisme (WS-I) specialement charge d'etablir et de veiller au respect des regies d'interoperabilite (voir 
chapitre 17 : « Le defi de l'interoperabilite »). 

Ce qui devient structurant aujourd'hui est done le support du concept de service. L element cle est la 
prise en compte de cette notion dans 1' architecture du systeme d'information et dans le choix des 
logiciels qui participent au fonctionnement de ce systeme. II convient done d'etre extremement vigi- 
lant quant au support des nouvelles specifications par les editeurs d'environnements d'execution et de 
developpement. Les chapitres qui suivent devoilent l'offre technologique des principaux editeurs qui 
soutiennent le concept de service Web. 

II faut egalement noter le role grandissant du mouvement Open Source dans le cadre de l'activite 
bouillonnante suscitee par 1' emergence des technologies liees aux services Web. II suffit, pour s'en rendre 
compte, d'observer l'intense implication de la communaute Apache, par exemple, a travers ses sous- 
projets lies aux technologies XML et SOAP (Xalan, Xerces, Axis. . .), ou bien F emergence de la commu- 
naute Eclipse dans le domaine des environnements de developpement, ou bien encore F apparition de 
divers projets d'implementation des specifications .NET standardisees ou de la specification UDDI. 

La description (WSDL) d'un service comme pivot 

Quelle que soit la plate-forme d'execution retenue, l'important est que celle-ci sache manipuler des 
documents XML et plus particulierement WSDL. C'est en effet par eux que passe desormais l'inter- 
operabilite entre systemes heterogenes et ce sont ces documents qui permettent le decouplage indis- 
pensable entre composants, sous-systemes et systemes d'information. 

L interface de communication avec un service Web est formellement decrite dans le document 
WSDL. Ce document constitue done le pivot de la communication qui pourra s'etablir entre le four- 
nisseur du service et le(s) demandeur(s) du service. 

Comme nous l'avons vu precedemment dans le fonctionnement d'un annuaire UDDI public ou prive, 
la reference de la description abstraite du service peut etre detenue par une tierce partie. Cependant, 
ceci n'est pas une obligation. Un service peut etre offert et utilise dans le cadre d'une relation bilaterale, 
sans que d'autres acteurs interviennent dans cette relation. 

Description en tant que specification 

En tant que telle, la description WSDL d'un service peut etre vue comme une specification de ce service. 
Cette specification peut relever de differentes natures : technique, fonctionnelle, metier... Lorigine de 
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cette specification peut egalement etre tres diversifiee : elle peut provenir d'un acteur economique isole, 
d'une entite de normalisation intemationale ou nationale, d'un organisme de representation d'un secteur 
economique ou associatif, d'une instance methodologique interne a une entreprise, etc. 

Description en tant que documentation 

Plus qu'une specification d'un service Web, le document WSDL constitue egalement un referentiel 
documentaire precieux. En effet, il s'agit d'un document qui decrit une interface de systeme, un peu 
au meme titre que le role joue par une classe d' interface dans le framework J2EE ou .NET. Sa portee 
est cependant plus grande, dans la mesure ou, non seulement il donne des informations relatives au 
niveau applicatif et programmatique via la description des messages echanges et des types de 
donnees qui interviennent dans la communication, mais aussi et surtout il informe des protocoles de 
transport pris en charge et des formats de message reconnus. 

II est symptomatique de voir que la simple publication en ligne de tels documents sur des sites 
portails comme XMethods (http://www.xmethods.com) ou SalCentral (http://www.salcentral.com) est suffi- 
sante pour realiser les developpements necessaires a l'acces aux services decrits via ces documents. 
Les sections qui suivent vont illustrer toutes les possibilites ouvertes a travers l'exploitation des docu- 
ments WSDL par une nouvelle generation d'outils et d'environnements de developpement. 

IBM a meme pousse l'analogie avec la documentation Javadoc en proposant dans son environnement 
de developpement de services Web Services Toolkit, un outil de transformation de document WSDL 
dans un format HTML proche de celui offert par la plate-forme Java. 
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Figure 13-1 

Document WSDL du sendee Web Echo genere par I'outil wsdldoc.bat d'IBM. 
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Cet outil wsdl doc . bat est accessible dans le sous-repertoire bi n de la boite a outils WSTK. II suffit de 
lui specifier les parametres necessaires, dont la liste des fichiers WSDL a traiter et le repertoire de 
destination de la documentation generee. Par exemple, si nous utilisons cet assistant en lui passant en 
parametre le fichier Echo .wsdl genere dans la section « Transformer un composant en service », plus 
loin dans ce chapitre, par le produit SOAP Toolkit de Microsoft, nous obtenons un ensemble de 
fichiers au format HTML, dont la page d' index est reproduite figure 13-1. 

Une fois ce document genere, Futilisateur peut naviguer aisement entre les differents elements du 
document WSDL d'origine en cliquant simplement sur les liens correspondants : definitions de services, 
types, messages, liaisons, services types, etc. 

Methodes de developpement 

En premiere approximation, la description WSDL d'un service Web peut etre produite de deux 
manieres : 

• soit a partir d'un element du patrimoine applicatif existant de l'entreprise (retroconception a 
partird'uneclasse Java ou C++, d'un composant COM, CORBAouEJB...), et la description 
est alors generalement obtenue par introspection du code executable ou par inspection des 
descripteurs de deploiement ; 

• soit par production directe a partir d'un editeur WSDL ou par generation a partir d'un logiciel 
de conception. 

De maniere schematique, la premiere demarche est celle qui est utilisee a des fins d' integration et/ou 
de restructuration de systemes d' information. Elle est mise en oeuvre pour produire ce que Ton 
appelle parfois des services Web de premiere generation. La seconde demarche est utilisee pour realiser 
de nouvelles applications Web qualifiees de services Web de deuxieme generation. 

En pratique, la situation est un peu moins simple. Peter Brittenham dTBM Software Group a produit, 
en mai 2001, un document intitule Web Services Development Concepts (WSDC 1.0). Ce document 
decrit plus precisement « l'approche pour developper des services Web, du point de vue du deve- 
loppeur d'un fournisseur de services et du developpeur d'un client de ces services ». Le document 
s'acheve en faisant le lien entre les concepts decrits et leur application dans un environnement Java 
(voir http://www-3.ibm.com/software/solutions/webservices/pdf/WSDC.pdf). 

Du point de vue du fournisseur de services Web, Peter Brittenham decrit les quatre situations suivantes : 
Methodes de developpement vues par le fournisseur de services 



Nouvelle implementation 
Implementation existante 


Nouvelle interface de service 


Interface de service existante 




Approche green field 


Approche top-down 




Approche bottom-up 


Approche meet-in-the-middle 


1 



La methode de developpement d'un service Web, du point de vue du fournisseur du service Web, est 
conditionnee par la preexistence ou non de l'interface du service et de 1' implementation du service : 

• L'approche green field (que Ton peut traduire par « depart de zero ») est la situation la plus 
simple, oil rien n'existe et tout est a faire : dans cette situation, le developpeur cree Pimple- 
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mentation du nouveau service Web, a partir de laquelle il genere ensuite l'interface. Dans 
cette situation, l'interface et 1' implementation sont la propriete du fournisseur du service. 

• L'approche top-down est utilisee lorsque l'interface du service est deja definie. Dans cette 
situation, le developpeur produit une nouvelle implementation de cette interface, eventuelle- 
ment a l'aide d'un generateur de code. Cette situation est susceptible de se produire lorsque 
l'interface du service est standardised par une autorite metier par exemple. Dans ce cas, seule 
1' implementation est la propriete du fournisseur du service. 

• L'approche bottom-up correspond a la situation inverse : ici, c'est 1' implementation du 
service Web qui existe deja (il peut s'agir d'une classe Java ou C++, d'un composant COM, 
CORBA ou EJB, etc.). Dans cette situation, le developpeur expose une nouvelle interface, 
eventuellement a l'aide d'un generateur de code, la plupart du temps par introspection du 
code executable ou par inspection des descripteurs de deploiement. Dans cette situation, 
l'interface et 1' implementation sont la propriete du fournisseur du service. 

• L'approche me et-in-the -middle correspond a la situation ou l'interface du service existe deja 
et ou l'application qui sera utilisee pour l'implementer existe egalement. Dans cette situation, 
le developpeur doit etablir une correspondance entre l'interface de l'application et celle du 
service : ceci peut etre facilite par l'ecriture d'une classe d'encapsulation {wrapper) de 
1' implementation du service existant. Dans ce cas, seule 1' implementation est la propriete du 
fournisseur du service. 

Du point de vue du consommateur de service Web, Peter Brittenham decrit trois situations possibles : 
Methodes de developpement vues par le consommateur de service 



Construction 
Execution 


Liaison statique 


Liaison dynamique 


Liaison statique 


Liaison dynamique a la construction 


n/a 


Liaison dynamique a I'execution 



La methode de developpement d'un client du service Web, du point de vue du consommateur du 
service Web, est conditionnee par la methode de liaison (statique ou dynamique) au service Web utili- 
see par le client. La liaison est realisee via la generation d'un proxy-service a partir de l'interface du 
service : 

• La liaison statique est utilisee lorsqu'une seule implementation du service est utilisee en 
execution. Dans cette situation, la liaison est generee a la construction a partir de la definition 
de 1' implementation de 1' unique service mis en oeuvre qui reference l'interface du service a 
utiliser pour la generation. 

• La liaison dynamique a la construction est utilisee lorsque l'interface de service est connue a 
la construction, mais pas l'application qui implemente cette interface, qui ne sera connue qu'a 
I'execution. 

• La liaison dynamique a I'execution est utilisee lorsque l'interface de service n'est connue 
qu'a I'execution. Dans ce cas, lorsque l'interface est decouverte, le proxy-service est genere 
et compile a la volee, puis execute dans la foulee. 
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Comme nous venons de le voir, il n'existe pas une methode universelle de developpement d'un 
service Web, cote fournisseur ou cote client, mais bien plusieurs methodes selon la situation dans 
laquelle nous nous trouvons. Aucune de ces methodes ne fait appel aux memes outils de developpe- 
ment. La suite de ce chapitre illustre certaines des demarches de developpement que nous venons de 
decrire et montre comment peuvent etre utilises certains de ces environnements. 

WSDL dans la pratique 

En pratique, lorsque le document WSDL ne fait pas Fobjet d'un standard ou d'une negociation entre 
fournisseur et demandeur, le developpeur de services Web n'a pas vocation a le rediger lui-meme. La 
production de ce document est generalement prise en charge via l'utilisation de generateurs qui 
s'appliquent au service qu'il vient de developper et mettre au point. 

Ces generateurs sont en effet capables d'exprimer une description en format WSDL a partir, d'une 
part d'une implementation particuliere d'un service, ecrit par exemple en langage Java ou C#, et 
d' autre part de directives de generation (telles que, par exemple, l'espace de noms auquel est ratta- 
chee F implementation du service). 

Ces outils sont souvent egalement couples a des generateurs de proxy-objets ou proxy-services qui 
realisent dans la pratique l'appel reel des implementations des services decrits ainsi que la recupera- 
tion du resultat de l'appel de ces services. La generation de ces proxy-services, suivant la plate-forme 
utilisee, peut etre realisee de maniere statique, c'est-a-dire durant la phase de developpement du 
projet Web, ainsi les proxy-services font partie integrante des livrables de cette phase. Les plates- 
formes Microsoft .NET ou IBM WSTK (Web Services Tool Kit) offrent cette possibilite. Cette gene- 
ration peut egalement etre effectuee a la volee, de maniere dynamique, au moment meme de l'invo- 
cation du service. La plate -forme d' execution est dans ce cas capable de generer automatiquement le 
proxy-service qui correspond a la description WSDL du service invoque, puis d'appeler automati- 
quement le proxy-service ainsi genere. Le produit Glue de la societe The Mind Electric prend en 
charge ce mode de fonctionnement. 

Transformer un composant en service 

Une premiere maniere de creer un service Web consiste a prendre pour base de travail un composant 
existant, ecrit dans un langage classique et integre dans une plate-forme d' execution classique. La 
technique consiste a analyser les primitives d' appel de ce composant, generalement par introspection 
ou etude de son descripteur de deploiement, puis a generer a l'aide d'un assistant (wizard), le docu- 
ment WSDL qui representera la future description de service et permettra d'invoquer les primitives 
du composant que le concepteur du service aura choisi d'exposer. 

Nous allons illustrer cette demarche au travers de deux outils qui offrent cette caracteristique : 

• le Microsoft SOAP Toolkit ; 

• le CapeStudio de Cape Clear. 

Microsoft SOAP Toolkit 2.0 SP2 et 3.0 

L'un des premiers outils de generation de documents WSDL disponibles est apparu dans le SOAP Tool- 
kit de Microsoft. Celui-ci est destine a permettre le developpement de services Web sur les plates- 
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formes logicielles Windows existantes, c'est-a-dire qui ne disposent pas, de maniere native, des capaci- 
tes offertes par le framework .NET. Le SOAP Toolkit est disponible en version 2.0 Service Pack 2 (voir 

http://msdn. microsoft, com/code/default, asp ?url=/code/sample. asp ?url=/msdn-files/027/00 1/580/msdncomposite- 
doc.xml) et une nouvelle version 3.0 plus evoluee est apparue durant Fete 2002 (voir http://msdn.micro- 
soft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/948/msdncompositedoc.xml). 

C'est la version 2.0 Service Pack 2 qui est ici mise en ceuvre. Cette version du SOAP Toolkit est 
compatible avec les plates-formes d'execution suivantes : 

• objets clients SOAP : Windows 98, Windows ME, Windows NT 4.0 Service Pack 6, et 
Windows 2000 Service Pack 1 ; 

• objets serveurs SOAP : Windows 2000 et Windows NT 4.0 Service Pack 6, soit sous forme 
d'un filtre IS API (Internet Server API), soit sous forme de pages ASP (Active Server Pages). 

Cet outil, en realite un assistant de generation graphique, permet de generer et d'exposer les services 
offerts par des composants COM developpes par n'importe quel atelier de developpement. L' assis- 
tant genere la description WSDL du service ainsi propose, la description WSML (Web Services Meta 
Language) propre a Microsoft qui decrit la liaison (mapping) entre la description des methodes du 
service en format WSDL et Fappel des fonctions equivalentes du composant COM. 

Le premier ecran affiche par cet outil (voir - figure 13-2) permet le nommage du service qui va etre cree. 
Ce nom sera utilise pour creer les fichiers WSDL et WSML correspondants. Le second champ de saisie 
est utilise pour designer la localisation du composant COM qui constitue F implementation du service 
en cours d' elaboration et qui sera ainsi encapsule. Ici, le service Web sera nomme Echo et son imple- 
mentation est fournie par la dll (Dynamic Link Library), EchoSvcRpcCpp.dll stockee dans le repertoire 
C:\Pi"ogi - amFiles\MSSOAP\Samples\Echo\Service\Rpc\CppSi"v\ReleaseUMinDependency. 



( .; SOAP Toolkit 2.0 Wizard 



Select the COM .dll file to analyse. 



What would you like to name your service? (This will become your WSDL and 
WSML file narnel 

| Echo 
Local path: | C: SProgram FilesW S S 0APSS amplest c |_ Select CDM ob|a:t | 



Figure 13-2 

Page de selection du composant COM a encapsuler. 



Lecran de Fassistant presente figure 13-2 propose une liste des methodes du composant COM parmi 
lesquelles le concepteur du service Web doit choisir celles qui seront exposees via son service. Ici, les 
methodes EchoString, Echolnt et EchoXML ont ete selectionnees. 
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( . SOAP Toolkit 2.0 Wizard 



J£l 



Select the services you would like to expose. 

You can select which services you would like to expose in your WSDL file for your 
'Web Service. 



Note- 




Only select the methods that 
you would like to expose. The 
wizard will exclude any methods 
you do not select. 

If you select a method that uses 
datatypes not supported by the 
Soap Toolkit, the questionable 
type will have (he data type 
"????????'■ in the WSDL file. 
This must be changed to a 
supported type before the 
WSDL file is used. 



About 



Cancel 



< Back 



Next? 



Finish 



Figure 13-3 

Page de selection des methodes exposees. 

La procedure s'acheve par la selection du type d'objet a Fecoute des requetes des futurs utilisateurs du 
service Web (SOAP listener) : cet objet peut etre soit un filtre ISAPI, soit une page ASP. L'URI d'acces 
ail listener SOAP doit egalement etre fourni dans cet ecran. Enfin, le concepteur du service peut selec- 
tionner la version de Fespace de noms de la specification XML Schema (1999, 2000 ou 2001). 



I" .; SOAP Toolkit 2.0 Wizard 



*} 



SOAP listener information 

Please specify your SOAP listener location and listener type below. 



Please enter a valid URI folder where your listener will be located. 
Listener URI — 



UR| : |http:/A)calhosrVEchc| 



(Example: http:/Vservername/soaplisten/') 



Listener type — 






r asp 




tr isapi 



■XSD Schema Namespace (2001 prefered)- 
[2001 



~3 



About 



Cancel 



c Back 



NextJ 



Finish 



Figure 13-4 

Page de localisation du listener SOAP. 
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Le dernier ecran de l'assistant permet de choisir l'encodage a utiliser pour la production du fichier 
WSDL (UTF-8 ou UTF-16), ainsi que le repertoire ou seront stockes les fichiers generes. 



f ■: SOAP Toolkit 2.0 Wizard 



xj 



Specify the location for the new WSDL and WSML files. 

The wizard will save the files in this folder. These files should be Web accessible in 
order to be exposed as Web Services. 



■Select WSDL file character set- 
F UTF-8 



C UTF-1G 



Where would you like to store the new files? 
| C: \\ ne tpub\wwwroot\E cho| 



About 



Cancel 



< Back 



Select 



Newt > 



Finish 



Figure 13-5 

Page de localisation des fichiers generis. 



f '.; SOAP Toolkit 2.0 Wizard 



ill 




Congratulations! Your WSDL and WSML files have been 
successully created for you. 



Figure 13-6 

Page de confirmation de la generation des fichiers. 



Finalement, la mise en ceuvre de cet assistant aura permis de rendre accessible cet objet serveur ecrit 
en C++ a partir d'Internet et cela de maniere tres simple. 
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Le resultat de F utilisation de cet assistant est materialise par la production de trois fichiers situes dans 
le repertoire C:\Inetpub\wwwroot\Echo : 

• le fichier Echo. asp : constitue le proxy-service ; 

• le fichier Echo. wsdl : contient la description du service Web ; 

• le fichier Echo. wsml : contient le mapping d'acces au serveur COM. 

Cet outil graphique de generation de proxy-services est double par un outil utilisable en mode ligne 

de commande ou dans des fichiers de scripts : wsdlstb.exe. 

La representation WSDL ainsi generee, a partir de 1' implementation C++ du serveur, est presentee 

ci-apres. 

Declarations des espaces de noms : 

<?xml version^' 1.0' encoding='UTF-8' ?> 

<!-- Generated 03/02/02 by Microsoft SOAP Toolkit WSDL File Generator, Version 1.00.623.0 --> 

definitions name ='Echo' 

targetNamespace = 'http://tempuri.org/wsdl/' 

xmlns:wsdlns='http://tempuri .org/wsdl /' 

xmlns:typens='http://tempuri .org/ type' 

xmlns:soap=' http://schemas.xml soap.org/wsdl /soap/ ' 

xmlns:xsd=' http://www.w3.org/2001/XMLSchema' 

xmlns:stk=' http://schemas.mi crosoft.com/soap-tool kit/wsdl -extension' 

xmlns=' http://schemas.xml soap. org/wsdl / '> 

Definition des types de donnees : 

<types> 

<schema targetNamespace='http://tempuri .org/type' 
xmlns=' http://www.w3.org/2001/XMLSchema' 
xmlns:S0AP-ENC='http: / /schema s.xml soap.org/soap/encoding/ ' 
xmlns: wsdl =' http://schemas.xml soap.org/wsdl /' 
elementFormDefault='qual ified'> 
<complexType name =' EchoServer. EchoXML. Result '> 
<sequence> 

<any minOccurs='0' maxOccurs='unbounded' namespace='#any ' 
processContents='skip'/> 
</sequence> 
</complexType> 

<complexType name =' EchoServer. EchoXML. X'> 
<sequence> 

<any minOccurs='0' maxOccurs='unbounded' namespace='#any' 
processContents='skip'/ 
</sequence> 
</complexType> 
</schema> 
</types> 

Declaration des messages : 

<message name=' EchoServer. EchoXML '> 

<part name='X' type='typens:EchoServer. EchoXML. X'/> 
</message> 
<message name=' EchoServer. EchoXMLResponse'> 

<part name=' Result' type='typens: EchoServer. EchoXML. Result'/> 
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</message> 

<message name='EchoServer. Echolnt '> 

<part name=T type='xsd:int'/> 
</message> 
<message name='EchoServer. EchoIntResponse'> 

<part name='Resul t' type='xsd:int'/> 
</message> 
<message name='EchoServer. EchoString'> 

<part name='S' type='xsd:string'/> 
</message> 
<message name='EchoServer. EchoSt ring Response '> 

<part name=' Result' type='xsd:string'/> 
</message> 

Declaration de F ensemble d' operations prises en charge (Port Type) : 

<portType name=' EchoServerSoapPort'> 

<operation name='EchoXML' parameterOrder='X'> 
<input message='wsdlns:EchoServer.EchoXML' /> 
<output message='wsdlns:EchoServer.EchoXMLResponse' /> 

</operation> 

<operation name='EchoInt ' parameterOrder=' I '> 
<input message='wsdlns:EchoServer.EchoInt ' /> 
<output message='wsdlns: EchoServer.EchoIntResponse' /> 

</operation> 

<operation name='EchoString' parameterOrder='S'> 
<input message='wsdlns:EchoServer.EchoString' /> 
<output message='wsdlns: EchoServer.EchoStringResponse' /> 

</operation> 
</portType> 

Definition de la liaison avec le protocole de transport SOAP pour cet ensemble : 

<binding name='EchoServerSoapBinding' type='wsdlns:EchoServerSoapPort' > 
<stk: binding preferredEncoding='UTF-8' /> 
<soap:binding style='rpc' 

transport='http://schemas .xmlsoap.org/soap/http' /> 
<operation name='EchoXML' > 

<soap: operation soapAction='http://tempuri .org/action/EchoServer.EchoXML' 

/> 

<input> 

<soap:body use=' encoded' namespace='http://tempuri .org/message/ ' 
encodingStyle=' http://schemas.xml soap.org/soap/encoding/' /> 
</input> 
<output> 

<soap:body use=' encoded' namespace='http://tempuri .org/message/ ' 
encodingStyle=' http://schemas.xml soap.org/soap/encoding/' /> 
</output> 
</operation> 
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<operation name='EchoInt' > 

<soap: operation soapAction='http://tempuri .org/action/EchoServer.EchoInt' 

/> 

<input> 

<soap:body use=' encoded' names pace='http://tempuri .org/message/' 
encodingStyle=' http://schemas.xml soap. org/ soap/encoding/' /> 
</input> 
<output> 

<soap:body use=' encoded' names pace='http://tempuri .org/message/' 
encodingStyle=' http://schemas.xml soap.org/soap/encoding/' /> 
</output> 
</operation> 

<operation name='EchoString' > 
<soap:operation 

soapAction='http://tempuri .org/action/EchoServer. EchoString' /> 
<input> 

<soap:body use=' encoded' names pace='http://tempuri .org/message/ ' 
encodingStyle=' http://schemas.xmlsoap.org/soap/encoding/' /> 
</input> 
<output> 

<soap:body use=' encoded' names pace='http://tempuri .org/message/ ' 
encodingStyle=' http://schemas.xmlsoap.org/soap/encoding/' /> 
</output> 
</operation> 
</binding> 

Definition du service Web et d'un port accessible par le protocole SOAP : 

<service name='Echo' > 

<port name=' EchoServerSoapPort' binding='wsdlns:EchoServerSoapBinding' > 
<soap:address location='http://myservername/Echo/Echo.ASP' /> 
</port> 
</service> 
</definitions> 



L'espace de noms par defaut : « http://tempuri.org » 

Le document genere utilise des prefixes associes a des espaces de noms dont la valeur (URI) debute par la chaine 
de caracteres http://tempuri.org. Cette chaine de caracteres est generique et produite lors de chaque utilisation du 
generateur. II convient bien entendu de retoucher le document WSDL genere afin de rendre ces espaces de noms 
uniques et appropries a chacun des services Web ainsi decrits. 



Le nouveau document genere par l'utilitaire SOAP Microsoft peut maintenant etre appele directe- 
ment a partir du programme client EchoCliRpcVb.exe fourni dans l'exemple Echo du toolkit. Ce 
programme, ecrit en Visual Basic recupere le document WSDL a Fadresse fournie par l'utilisateur, 
effectue une analyse syntaxique du document et realise 1' invocation des methodes du service, en 
passant les parametres fournis via l'interface a destination du serveur qui implemente ce service (ici, 
le listener SOAP en technologie ASP, genere en meme temps que le document WSDL). 



Les plates-formes operationnelles 

Troisieme Partie 



a. SOAP SDK Echo Tester 



WSDL: 
Data Type — 
(• Echolnt 
C Echo String 
r EchoXML 



ittD://localhcst.€chc./Echo.WSDL 



3 



Test Court: 

String Length: 

XML Elements: 

XML Content Length: |~ 



2 W Reuse Client 
— I - Verify Result 



Complete Count: 
Seconds: 
Per Second: 



2 

0,02 

102,40 



Start 



Stop 



Figure 13-7 

Application du client de test au document WSDL genere. 



Cape Clear CapeStudio 3.0.1 

La societe Cape Clear, basee a Dublin et creee en septembre 1999 par d'anciens dirigeants de IONA 
Technologies, a ete Time des premieres entreprises a proposer un environnement d'execution, Cape- 
Connect, apte au deploiement de services Web. Cette plate-forme est maintenant completee par un 
studio, nomme CapeStudio, dont Fobjectif est de permettre la conception, le developpement et le 
deploiement de services Web a partir de composants existants. 

La plate-forme de Cape Clear, d'emblee specialised dans l'encapsulation de composants CORBA et 
EJB, du fait de l'origine des createurs de la societe, est desormais capable de deployer des services 
Web issus de composants Java purs ou COM. 

Plus precisement, le generateur WSDL prend en charge les EJB 1.0, 1.1 et 2.0. II genere egalement 
les fichiers WSML propres aux composants COM de Microsoft. Cet outil exploite les fichiers IDL de 
description d'interfaces des objets CORBA. Pour les composants Java, il peut utiliser un ou plusieurs 
fichiers JAR qui contiennent les composants. Lorsque les composants Java ou CORBA utilisent des 
types de donnees complexes, le generateur produit egalement un fichier de liaison correspondant 
{mapping). Les differents types de composants ne peuvent pas etre mixes dans un meme service Web. 

Ces produits sont compatibles avec de nombreuses plates-formes d'execution dont : 

Microsoft Windows NT 4.0 SP6a, Windows 2000 SP1 ou SP2 ; 

Sun Solaris 2.6 et 2.8 ; 

Linux Red Hat 7.2 ; 

SunJDK1.3.1_0x; 

BEA WebLogic Enterprise 5.1 ; 

BEA WebLogic Server 5. 1 et 6. 1 ; 

IBM WebSphere Application Server 3.5, 4.0 et ulterieures ; 

iPlanet Application Server 6.5 ; 

IONA Orbix 2000 2.0 (C++ and Java) ; 

IONA OrbixWeb 3.2 ; 

Borland VisiBroker 4.5 (Java and C++), etc. 
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L'offre de Cape Clear vient d'evoluer a nouveau et la version 4 est maintenant disponible (voir http:// 
www. capeclear. com/products) . 

Nous allons illustrer avec quelle simplicite le CapeStudio permet de generer le fichier WSDL qui 
correspond a l'exemple d'EJB Transfer inclus dans le produit WebSphere Application Server 4.0 
d'IBM. Cet exemple d'EJB implemente deux methodes de gestion d'un compte, prealablement cree 
par un autre EJB Account present dans la demonstration d'IBM. Ces deux methodes implementent les 
fonctions suivantes : 

• getBal ance permet d'obtenir le solde du compte passe en parametre ; 

• transf erFunds realise le transfert d'un certain montant entre deux comptes passes en parametres. 

L' atelier CapeStudio regroupe toutes les fonctions necessaires a la gestion de projets, a la conception, 
au developpement, a 1' integration et au deploiement de services Web (voir figure 13-8). 



I CapeStudio Developer Center 



Project Design Develop Integrate Deploy Help 



_lD|x| 



^] 



GipcSludkJ 



Welcome to the CapeStudio Developer Center. 

To start using trie Developer Center, create a new project using the "New" 
menu item on the "Project' menu or open an existing project. 



r 



Figure 13-8 

Ecran d'accueil de CapeStudio. 

La premiere etape consiste a creer, a l'aide du menu Projet, un projet de service Web que nous intitu- 
lerons Transfer WAS. 



To create a new project enter a name for the project file and a directory to 
place project flies in. A WSDL file may optionally he added now, or created 
later using one of the CapeStudio design tools. 



Transfer WAS 



Directory: 



C:\CapeCleai\Projecls\iransfer_WAS 



Browse.. 



WSDL File: 



OK 


Cancel 



Figure 13-9 

Creation du projet Transfer _W 'AS. 



Les plates-formes operationnelles 

Troisieme Partie 

Lors de la creation d'un projet, il est egalement possible de preciser d'emblee la localisation d'un 
fichier WSDL existant. 



W Transfer WAS.csp - CapeStudio Developer Center 



roject Design Develop Integrate Deploy. Help 



nJ_*l 



Project 

k i 







Capcijlud'nj 



- [J Transfer_WAS 

□ [Add a WSDL file to the project in order to proceed] 

\J Server Implementation 

£j EJB Server Implementation 

[J Java Client 

O Wep Client 

CJ< Visual Basic Client 



L 



[J Transformation 



Figure 13-10 

Elements du projet Transfer _WAS. 



L'ecran figure 13-10 presente les differents elements d'un projet de service Web sous CapeStudio. 
Celui-ci est constitue des composants suivants : 

• un ou plusieurs documents WSDL ; 

• une implementation serveur du service Web geree par CapeConnect ; 

• une implementation serveur EJB du service Web geree par CapeConnect ; 

• un client Java de test du service Web ; 

• un client Web de test du service Web ; 

• un client Visual Basic de test du service Web ; 

• un outil de transformation de documents XML (XSLT). 

La generation d'un document WSDL a partir d'un composant existant est realisee via l'utilisation du 
menu Design/Generate WSDL From Java/J2EE/CORBA. . . Cette action permet de choisir le type de 
composant que Ton souhaite encapsuler (EJB, Java ou CORBA). Pour notre exemple, il s'agit d'un 
composant EJB dont la localisation est precisee par l'intermediaire du bouton Add. II est possible de 
fournir ici plusieurs fichiers d' archives Java (JAR). Dans notre cas, le seul fichier necessaire est situe 
dans l'arborescence des exemples de WebSphere Application Server 4.0 : C:\WebSphere\AppServer\ 
installedApps\Samples.ear\AccountAndTransferEJBean.jar. 
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■ Generate W5DL From Java/JZEE/CORBA 



Web Service Name: 




Transfer WAS 



Component Type:® EJB O Java O CORBA 
Components: 




Output Directory: 




Remove All 




Add 



C:\CapeCleartProjects\Transfer_WAS 



Cancel 


Settings 



Figure 13-11 

Recuperation dufichier JAR de WebSphere 4.0. 

L'ecran figure 13-12 permet de selectionner les composants EJB que Ton souhaite utiliser pour la 
phase de generation, ainsi que les interfaces qui doivent etre exposees. 



Transfer WAS.wsdl - Generate WSDL From Java/ J2EE/CORBA 



3Tra nsfer_WAS 

AccountAndTransferEJBean 



<r 



Cancel 



in 



set all □ Select none 



E Expose Interface 



Transfer 



JNDI Name: 



|WSsamp I e sfTra n sferHome 



Figure 13-12 

Selection des composants EJB a exposer. 



n|x| 



« Previous 


Finish 
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Le nom JNDI est propose a partir de l'element e j b-name du descripteur de deploiement du composant 
EJB, sauf pour le serveur WebLogic pour lequel il est recupere de l'element jndi-name du fichier 
weblogic-ejb-jar.xml. Dans notre exemple, il doit etre remplace parWSsamples /Trans ferHome tel que 
le precise la commande dumpNameSpace.bat de WebSphere. L'etape suivante du processus consiste a 
assembler les elements necessaires au deploiement final du service ainsi constitue (packaging). Les 
elements qui entrent dans la composition d'un tel assemblage peuvent etre : 

• lefichierWSDL; 

• un fichier WSML en cas d' encapsulation d'un composant COM ; 

• un fichier de mapping de types (extension .map) propres a CapeStudio ; 

• des composants Java ; 

• des souches CORBA (stubs). 

Cet assemblage est produit sous la forme d'un fichier WSAR (Web Service Archive). La generation 
de cette archive est declenchee par F utilisation du menu Deploy /Package. . . Dans notre exemple, seul 
le fichier WSDL genere est necessaire au fonctionnement du service Web qui va etre deploye. 



Package in a WSAR file. 

Package your serverfiles into a WSAR file that can be used to deploy the Web Service in your 



WSAR File: 



C AC a p e C I e a rtP r o j e ctsVTra n sfe r_WASVTr a n sfe r_WAS .ws a r 



File Type 


File Name 


WSDL File: 


C:\CapeCleanProjects\Transfer WASVTransfer WAS.wsdl 





Create 




Cancel 



Figure 13-13 

Generation de V archive WSAR du service Web. 



II ne reste plus qu'a publier le nouveau service Web vers la plate-forme d' execution CapeConnect, en 
charge de 1' exploitation des services Web deployes. Cette publication du service est realisee via le 
menu Deploy/Deploy Service... 

L'ecran suivant permet de specifier si toutes les interfaces presentes dans le projet doivent etre execu- 
tees sur le meme serveur ou sur des serveurs differents. II est possible en effet que certains compo- 
sants necessaires au fonctionnement du service Web con§u soient operationnels sur des plates-formes 
d'execution differentes. Cet ecran propose egalement de realiser un deploiement securise du nouveau 
service Web. 
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Transfer WAS.wsar - Deploy Service 



^JflJjSl 



rjTransfer_WAS 
Q TransferHome 






= ^ 

Settings 



Selecting a server here sets it for all of trie interfaces si 
All interfaces use the same server 



websphere_40 



Description: 



Make the Web service secure by requiring the clients 
of the service log on before using it. 

□ Make deployed Web service secure 



Deploy 


Cancel 



Figure 13-14 

Choix du serveur d' execution du composant EJB. 

En cas de publication partielle des fonctions proposees par le service Web, il est possible de selec- 
tionner les ports WSDL correspondants par 1' intermediate de l'ecran represente figure 13-15. 



Transfer WAS.wsar - Deploy Service 



^lflj_x| 



~3Tra nsfer_WAS 
TransferHome 



Settings 



Select the server for this interface. If you want all of your 
interfaces to share the same server, select the server 
onthe main panel. 



Server: 



websphere_40 



Description: 



Select a WSDL port for the component selected on 
the tree. 
Services: 



Transfer. WAS 



Transfer 



Deploy Cancel 



Figure 13-15 

Selection des ports exposes par le service Web. 
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Une fois le service Web deploye sur la plate-forme CapeConnect, celui-ci peut etre immediatement 
teste. Apres avoir prealablement demarre le serveur WebSphere, il est possible d'effectuer ce test via 
le menu Deploy/Web Service Tester. Pour cela, il suffit de creer deux comptes avec l'outil de 
demonstration de WebSphere : par exemple, un compte n° 123456 dont le solde est de 12 000 €, etun 
compte n°654321 credite de 24 000 €. 



5 Create a new Account EJB - Wanadoo, Internet avec France telecom j 


Fichier Edition AFfichage Favoris Outils ? 




J Adresse http://mymachine/WebSphereSample5/SingleSamples/AccountAndTransfer/creal:ejsp.hl:rinl ^J (j^OK 




Liens » 


J Precedents Suivante Arreter Actualiser Demarrage 


Wanadoo 


@ Si ,J 

Rechercher Favoris Historique 




c 


!reate a new Account 


J 




Account Number: 


123^56 






Type: | P savings | C checking 




Starting Balance: 


12000 












Create | 




£] Termine (z£ Intranet local 



Figure 13-16 

Creation de deux comptes sur le serveur WebSphere. 



La bonne execution, par exemple, de la methode transferFunds du service Web en passant comme 
parametres la somme de 4 000 € du compte n°654321 vers le compte n° 123456, saisis directement 
dans le corps de la requete SOAP (a gauche de l'ecran), se traduit par le renvoi de la reponse SOAP 
de confirmation de 1' operation ci-apres (a droite de l'ecran, figure 13-17). L'envoi de la requete 
s'effectue par le menu Message/Send. 

De meme, la bonne fin de cette operation de transfert entre comptes peut etre controlee, toujours 
par le meme outil, en activant la seconde operation exposee par le service Web. II suffit pour cela 
d'executer la methode getBalance du service Web en passant comme parametre le compte 
n° 123456, saisi directement dans le corps du message SOAP de requete (a gauche de l'ecran, 
figure 13-17). Le solde du compte est bien maintenant de 16 000 € au lieu des 12 000 € initiaux : 
voir la valeur du type flottant de retour dans le message SOAP de reponse de l'operation ci-apres 
(a droite de l'ecran, figure 13-18). 
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Location: http://solaris.riagoraxorn:85GG/cc>(/Trarisfer_WAS -*• SQAPAction: capeconnect:TransferJ^AS:V^Ssamples/TransferHome#lrarisferFunds 



Binding: 



TransferBinding 



▼ Operation: 



transferFunds 



Request Message 



:?xrnl version="1 .0" encoding="UTF-8"?> 
:SOAP-ENV:Envelope 
xmlns:SOAP-ENV- 'http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encoding/" 
xm I n s :xs d=" http ://www. w3 . o rg/2 1 /XM LS c h e m a" 
xmlns:xsi- 'http://www.w3.org/2001/XMLScherna-instance" 
xrnlns:nsO-'capeconnect:Transfer_WAS:WSsamplesrTransferHome" 
SOAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body> 
<nsO:transferFunds> 
<argO xsi:type="xsd:int'>654321 </argO> 
<arg1 xsi:type="xsd:int'>1 23456</arg1 > 
<arg2xsi:type="xsd:float'>4000</arg2> 
< a rg 3 xs i :typ e="xs d : stri n g" > </a rg 3 > 
</nsO:transferFunds> 
*/SDAP-EMV:Body> 
:/SOAP-ENV:Envelope> 



Switch between formatted and unformatted view of the response message 



Response Message 



:?xml version="1.0"?> 
:SOAP-ENV:Envelope 
xmlns:SOAP-ENV- 'http://schemas.xmlsoap.org/soap/envelope/" 
xm I n s :xs d=" http ://www. w3 . o rg/2 1 /XM LS c h e m a" 
xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body 
SQAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encoding/"> 
<cd :transferFundsResponse 
xmlns:cc1-'capeconnect:Transfer_WAS:WSsamples/TransferHome" 
SOAP-ENC:root="1"> 
:/cd :transferFundsResponse> 

</SOAP-ENV:Body> 
:/SOAP-ENV:Envelope> 



Figure 13-17 

Test du transfert defends entre deux comptes sur le serveur WebSphere. 



Transfer WAS.wsdl - CapeStudio Web Service Tester 



File Message Help 



njxj 



^ -T 
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CapcStudu 



http://solaris.nagora.com:8500/cc>ciTr'ansfer_WAS 



SO AP Action: capeconne ct:Tra n sfe r_WAS :WS s a m p 1 8 s/Tr a n sfe rH o m e#g etB a I a n c e 



Binding: TransferBinding 



v Operation: getBalance 



Request Message 



:?xml version="1 .0" encoding="UTF-8"?> 
■SOAP-ENV:Envelope 
xmlns:SOAP-ENV- 'http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encodingr 
xm I n s :xs d=" http ://www. w3 . o rg/2 1 /XM LS c h e m a" 
xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" 
xmlns:nsO-'capeconnect:Transfer_WAS:WSsamples/TransferHome" 
SOAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body> 
<nsO:getBalance> 
<argO xsi:type="xsd:int'>1 23456</arg0> 
< a rg 1 xs i :typ e="xs d : stri n g" > </a rg 1 > 
</nsO:getBalance> 
</SOAP-ENV:Body> 
:/SOAP-ENV:Envelope> 



r 



Response Message 



<?xml version="1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV- 'http://schemas.xmlsoap.org/soap/envelope/" 
xm I n s :xs d=" http ://www. w3 . o rg/2 1 /XM LS c h e m a" 
xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body 
SOAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encodingr- 
<cd :getBalanceResponse 
xmlns:cc1-'capeconnect:Transfer_WAS:WSsamples/TransferHome" 
SOAP-ENC:root="1"> 

< retu rn xs i :typ e="xs d :fl o at' > 1 6 . </retu rn > 
=:/cc1:getBalanceResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



Figure 13-18 

Verification du solde du compte n° 123456 a partir de CapeStudio. 



Les plates-formes operationnelles 

Troisieme Partie 



Le solde du compte emetteur n°654321, quant a lui, est bien passe d'un montant de 24 000 € a la 
somme de 20 000 €, comme Fatteste l'ecran de verification suivant (figure 13-19). 



Transfer WAS.wsdl - CapeStudio Web Service Tester 



File Message Help 
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SOAPAction: c a p e c o n n e ct:Tra n sfe r_VVAS : VVS s a m p I e s/Tra n sfe rH o m e#g etB a I a n c e 



Binding: TransferBinding 



» Operation: getBalance 



Request Message 



<?xml version="1 .0" encoding="UTF-8"?> 
SOAP-ENV:Envelope 

xmlns:SOAP-ENV- 'http://schemas.xmlsoap.org/soap/envelope/' 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encoding/' 
xm I n s :xs d- ' http ://www.w3 org/2001/XMLSchema" 
xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" 
xmlns:nsO="capeconnect:Transfer_WAS:WSsamples/TransferHome" 
SOAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encoding/'> 
■sSOAP-ENV:Body> 
<nsO:getBalance> 
«argO xsi:type="xsd:inf>654321 </argO> 
< a rg 1 xs i :typ e- 'xs d : stri n g" ></a rg 1 > 
</nsO:getBalance> 
■s/SOAP-ENV:Body> 
«/SOAP-ENV:Envelope> 



Response Message 



<?xml version="1.0"?> 
:SOAP-ENV:Envelope 
xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/' 
xm I n s :xs d- ' http ://www.w3 . o rg/2 1 /XM LS c h e m a" 
xmlns:xsi- 'http://www.w3.org/2001/XMLSchema-instance" 
xmlns:SOAP-ENC- 'http://schemas.xmlsoap.org/soap/encoding/'> 
«SOAP-ENV:Body 
SOAP-ENV:encodingStyle- 'http://schemas.xmlsoap.org/soap/encoding/'> 
<cd :getBalanceResponse 
xmlns:cc1="capeconnect:Transfer_WAS:WSsamples/TransferHome" 
SOAP-ENC:root="1"> 

< retu rn xs i :typ e- 'xs d :fl o at ' > 2 . </retu rn > 
</cd :getBalanceResponse> 
«/SOAP-ENV:Body> 
:/SOAP-ENV:Envelope> 



Figure 13-19 

Verification du solde du compte n '654321 a partir de CapeStudio. 



Au final, le fichier WSDL ainsi genere par Foutil CapeStudio se presente ainsi. 
Declarations des espaces de noms : 

<?xml version="1.0" encoding="UTF-8"?> 
definitions 

name="Transfer_WAS" 

target Names pace=" http: //www. capeclear.com/Transfer_WAS.wsdl " 

xmlns=" http://schemas.xml soap.org/wsdl/" 

xmlns:soap=" http://schemas.xml soap.org/wsdl /soap/" 

xmlns:tns=" http: //www. capeclear.com/Transfer_WAS.wsdl " 

xmlns:xsd=" http: //www. w3.org/2001/XMLSchema" 

xmlns:xsdl=" http://www.capeclear.com/Transfer_WAS.xsd"> 

Declaration des messages de requetes et de reponses : 

<message name="getBalance"> 

<part name="argO" type="xsd:int"/> 

<part name="argl" type="xsd:string"/> 
</message> 
<message name="getBalanceResponse"> 

<part name="return" type="xsd:float"/> 



Principes de mise en oeuvre 

Chapitre 13 



</message> 

<message name="transferFunds"> 

<part name="argO" type="xsd:int"/> 

<part name="argl" type="xsd:int"/> 

<part name="arg2" type="xsd:float"/> 

<part name="arg3" type="xsd:string"/> 
</message> 
<message name=" transfer Funds Res ponse"/> 

Declaration de l'ensemble d'operations prises en charge (Port Type) : 

<portType name="Transfer"> 

<operation name="getBalance"> 

<input message="tns:getBal ance"/> 

<output message="tns:getBalanceResponse"/> 
</operation> 
<operation name=" transfer Funds "> 

<input message="tns:transferFunds"/> 

<output messa ge="tns: transfer Funds Res ponse"/> 
</operation> 
</portType> 

Definition de la liaison avec le protocole de transport SOAP pour cet ensemble : 

<binding name="TransferBinding" type="tns:Transfer"> 

<soap: binding style=" rpc" transport=" http://schemas.xml soap. org/ soap/http"/> 
<operation name="getBalance"> 
<soap:operation soapAction= 

"capeconnect:Transfer_WAS:WSsamples/TransferHome#getBalance"/> 
<input> 

<soap:body 

encodingStyle="http:/ /schema s. xmlsoap.org/ soap/encoding/" 
namespace="capeconnect:Transfer_WAS:WSsamples/TransferHome" 
use="encoded"/> 
</input> 
<output> 
<soap:body 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/" 
namespace="capeconnect:Transfer_WAS:WSsamples/TransferHome" 
use="encoded"/> 
</output> 
</operation> 

<operation name=" transfer Funds "> 
<soap:operation soapAction= 

"capeconnect:Transfer_WAS:WSsamples/TransferHome#transfer Funds "/> 
<input> 

<soap:body 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/" 
namespace="capeconnect:Transfer_WAS:WSsamples/TransferHome" 
use="encoded"/> 
</input> 
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<output> 
<soap:body 

encodingStyle=" http://schemas.xml soap.org/soap/encoding/" 
namespace="capeconnect:Transfer_WAS:WSsamples/TransferHoine" 
use="encoded"/> 
</output> 
</operation> 
</binding> 

Definition du service Web et d'un port accessible par le protocole SOAP : 

<service name="Transfer_WAS"> 

<documentation>Transfer_WAS</documentation> 
<port binding="tns:TransferBinding" name="Transfer"> 
<soap:address location= 

"http://sol aris.nagora.com:8500/ccx/Transfer_WAS"/> 
</port> 
</service> 

<!--Created by CapeConnect on Thu Jan 10 20:35:55 CET 2002 
See http://www.capeclear.com for more detai 1 s--> 
</definitions> 

En conclusion de ces transformations de composants COM et EJB en services, Finformation majeure 
a retenir est que dans ces deux exemples, absolument aucune modification des systemes d'informa- 
tion existants n'a ete necessaire. La reutilisation de composants techniques de natures differentes a 
ete rendue possible sans intrusion d' aucune sorte dans 1' architecture technique existante. 

Nous voyons bien ici que l'objectif premier des promoteurs de ces nouvelles technologies est parfai- 
tement atteint et offre ainsi l'opportunite de minimiser les efforts necessaires a une meilleure integra- 
tion des differents elements constituants du systeme d' information existant des entreprises. La conse- 
quence immediate est, bien sur, que les investissements informatiques ainsi economises peuvent etre 
reorientes vers d'autres priorites strategiques de Fentreprise ou bien, pour la premiere fois depuis 
longtemps, etre reaffectes vers de nouveaux projets informatiques au lieu d'etre geles dans une main- 
tenance couteuse des systemes existants. 



Generer un proxy-service a partir d'une description 

Lutilisation du service Web, decrit par son document WSDL ainsi genere, peut etre immediate, a 
travers l'invocation dynamique des operations definies dans le contrat du service. Cependant, il peut 
etre preferable, pour des raisons de performance par exemple, de generer des proxy-services, en 
charge notamment du traitement de conversion de types de donnees (marshalling/unmarshalling) ou 
du support des mode les d'appels synchrones/asynchrones, a partir de la description formelle du 
service. 

Cette fonction est egalement remplie par la plupart des grandes plates-formes de developpement ou 
par des outils dedies et autonomes. A partir de 1' exemple Echo etudie precedemment, nous allons ici 
illustrer cette fonctionnalite a Faide de deux outils differents : 

• le generateur du framework .NET de Microsoft ; 

• les outils du Web Services Toolkit dTBM. 
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Microsoft .NET Framework 

Le framework .NET de Microsoft (voir http://msdn.microsoft.com/netframework/default.asp) ne dispose pas 
d'un assistant graphique comme le SOAP Toolkit (sauf si on utilise le Visual Studio .NET : http:// 
msdn.microsoft.com/vstudio), mais il est cependant dote d'un outil de generation en mode commande : le 
Web Services Description Language tool (wsdl . exe). 

Cet utilitaire est capable de generer le proxy-service, pour un client ou un serveur, a partir d'un 
element descriptif du service fourni soit sous forme d'une URL, soit sous forme d'un chemin d'acces 
a 1' element descriptif. 

La syntaxe generate de cette commande est la suivante : 

wsdl [options] {URL | path} 
L element descriptif passe en parametre peut etre soit : 

• une description de service WSDL (.wsdl) ; 

• une description de schema (.xsd) ; 

• un document de decouverte (.disco ou .discomap). 

Cet utilitaire accepte de nombreuses options decrites dans le tableau 13-1. 

Tableau 13-1. Options de I'outil wsdl.exe du framework .NET 



Option 

/appsettingurlkey:/<ey 
/urlkey:tey 

/appsettingbaseurl:baseu/7 
/baseurlifcasew/ 

/d[omain]:cfoma/n 
/l[anguage]:/anguage 

/n[amespace] -.namespace 
nologo 

lo[u\]:filename 
/password] -.password 
/protocol -.protocol 

/proxy: URL 

/proxydomain : domain 
Ip&.domain 

/proxypassword -.password 
lpp:password 

/proxyusername: username 
/pu: user name 



Description 

Specifie une cle de configuration a utiliser par defaut pour rechercher la valeur de la propriete 
URL au moment de la generation du code. 

Specifie I'URL de base a utiliser lors du calcul du fragment d'URL. Ce fragment d'URL est 
calcule en convertissant I'URL relative a partir de cette valeur vers I'URL stockee dans le 
fichier WSDL. Cette option doit etre specifiee conjointement avec la precedents. 

Le nom de domaine a utiliser si le serveur necessite une authentification. 

Precise le langage a utiliser pour la generation pour la classe du proxy-service : CS (C# par 
defaut), VB (Visual Basic) ou JS (JScript). II peut egalement s'agir du nom qualifie d'une classe 
qui implements la classe System. CodeDom. Compiler. CodeDomProvider du framework. 

Specifie I'espace de noms a utiliser par la classe de proxy-service generee. 

Suppression de la banniere Microsoft. 

Indique au generateur le nom de fichier a utiliser pour enregistrer le code genere. 

Le mot de passe a utiliser si le serveur necessite une authentification. 

Specifie le protocole de communication a implementer : Soap (par defaut), HttpGet, Http- 
Post ou un protocole particulier specifie dans le fichier de configuration. 

L'URL du proxy-serveur a utiliser pour les requetes HTTP. Par defaut, ce sont les reglages 
proxy du systeme qui s'appliquent. 

Le nom de domaine a preciser si le proxy-serveur a utiliser necessite une authentification. 
Le mot de passe a preciser si le proxy-serveur a utiliser necessite une authentification. 
Le nom d'utilisateur a preciser si le proxy-serveur a utiliser necessite une authentification. 
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Tableau 13-1. Options de I'outil wsdl.exe du framework .NET (suite) 

Option Description 

/server Genere une classe abstraite de proxy-service cote serveur. Par defaut, le proxy-service 

genere est cote client. 

Le nom d'utilisateur a preciser si le serveur necessite une authentification. 

Affiche la syntaxe et les options de la commande. 



/u[sername]:usemame 

/? 



L' application de Fune ou Fautre des deux commandes ci-apres sur la description WSDL du service 
Echo, etudiee precedemment : 

iwsdl /out:C:\Inetpub\wwwroot\Echo\Proxy-Echo.cs /namespace: Echo C:\Inetpub\wwwroot\Echo\Echo.wsdl 
wsdl /out:C:\Inetpub\wwwroot\Echo\Proxy-Echo.cs /namespace: Echo http: //local host/Echo/Echo. wsdl 

produira la generation du proxy-service en langage C# suivant : 

// 

// 
// 
// 
// 
// 
// 
// 
ti- 
ll 
II 
II 



<autogenerated> 

This code was generated by a tool. 
Runtime Version: 1.0.3705.0 

Changes to this file may cause incorrect behavior and will be lost if 
the code is regenerated. 
</autogenerated> 



This source code was auto-generated by wsdl, Version=l .0.3705.0. 



Definition de Fespace de noms auquel appartient le proxy-service Echo : 

namespace Echo { 

using System. Diagnostics; 

using System. Xml .Serialization; 

using System; 

using System. Web. Services. Protocols ; 

using System. ComponentModel ; 

using System. Web. Services; 

Definition du proxy-service Echo : 

/// <remarks/> 

// C0DEGEN: The optional WSDL extension element 'binding' from namespace 

'http://schemas.microsoft.com/soap-toolkit/wsdl-extension' was not handled. 

[System.Diagnostics.DebuggerStepThroughAttribute( )] 

[System. ComponentModel .DesignerCategoryAttribute( "code")] 

[Sys tern. Web. Services. WebServiceBindingAttribute(Name="EchoServerSoapBinding" 

Namespace="http://tempuri .org/wsdl /")] 

public class Echo : System. Web. Services. Protocols. SoapHttpCl ientProtocol { 

/// <remarks/> 
public EchoO { 

this . U r 1 = "http://myservername/Echo/Echo.ASP" ; 
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Definition de la methode EchoXML du proxy-service Echo : 

/// <remarks/> 

[Sys tern. Web. Services. Protocol s.SoapRpcMethodAttribute( "http://tempuri .org/ 

a cti on /EchoServer. EchoXML" , Request Namespace="http://tempuri .org/message/" , 

ResponseNamespace="http://tempuri .org/message/" )] 

[return: System. Xml .Serial i za t i on. SoapElementAttributeC Result" )] 

public object EchoXMLtobject X) { 

object[] results = this. InvokeC'EchoXML" , new object[] {X}); 

return ( (object)(resul ts[0] ) ) ; 
} 

/// <remarks/> 

public System. IAsyncResult BeginEchoXMUobject X, System. AsyncCall back 
callback, object asyncState) { 

return this.BeginlnvokeC'EchoXML" , new object[] (X), callback, 
asyncState) ; 
} 

/// <remarks/> 

public object EndEchoXMUSystem. IAsyncResult asyncResult) { 

object[] results = this. EndInvoke(asyncResul t) ; 

return ( (object)(resul ts[0]) ) ; 
} 

Definition de la methode Echolnt du proxy-service Echo : 

/// <remarks/> 

[System. Web. Services. Protocol s.SoapRpcMethodAttribute( "http://tempuri .org/ 

a cti on /EchoServer. Echolnt" , Request Namespace="http://tempuri .org/message/" , 

ResponseNamespace="http://tempuri .org/message/")] 

[return: System. Xml .Serial izat ion. SoapElementAttributeC Result" )] 

public int Echolnttint I) { 

object[] results = this. Invoke( "Echolnt" , new object[] (I}); 

return ((int)(results[0] ) ) ; 
} 

/// <remarks/> 

public System. IAsyncResult BeginEchoInttint I, System. AsyncCallback 
callback, object asyncState) { 

return this.BeginlnvokeC'EchoInt" , new object[] {I), callback, 
asyncState) ; 
} 

/// <remarks/> 

public int EndEchoInt(System. IAsyncResult asyncResult) { 

object[] results = this. EndInvoke(asyncResul t) ; 

return ((int)(results[0] ) ) ; 
} 

Definition de la methode EchoStri ng du proxy-service Echo : 

/// <remarks/> 

Sys tern. Web. Services. Protocol s.SoapRpcMethodAttribute("http://tempuri .org/ 
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} 



action/EchoServer.EchoString" , 
RequestNamespace="http://tempuri .org/message/" , 
ResponseNamespace="http://tempuri .org/message/" )] 
[return: System. Xml .Serial ization.SoapElementAttribute( "Result" )] 
public string EchoString(string S) { 

object[] results = this. InvokeC'EchoString" , new object[] {S}); 

return ( (stringMresul ts[0]) ) ; 
} 

/// <remarks/> 

public System. IAsyncResult BeginEchoString(string S, System. AsyncCal 1 back 
callback, object asyncState) { 

return this.BeginlnvokeC'EchoString" , new object[] {S}, callback, 
asyncState) ; 
} 

/// <remarks/> 

public string EndEchoString(System. IAsyncResult asyncResult) { 

object[] results = this.Endlnvoke(asyncResult) ; 

return ( (stringMresul ts[0]) ) ; 



II faut remarquer ici, pour chacune des trois methodes du proxy-service, la presence de methodes nommees 
Begi nEchoXxx et EndEchoXxx associees. Ceci est du au fait que le framework .NET prend en charge a la fois les 
modeles d'appel synchrone et asynchrone de services. 



IBM Web Services Toolkit 3.1 

L'environnement de sensibilisation des developpeurs aux technologies de services Web produites par 
IBM dispose egalement d'un ensemble d'outils qui permettent de manipuler des documents WSDL, 
de les generer a partir d'une implementation existante et de generer une implementation a partir 
d'une description de service WSDL. 
Parmi ces outils, on peut citer : 

• l'utilitaire de generation WSDL java2wsdl ; 

• l'utilitaire de generation Java wsdl 2java ; 

• l'utilitaire de generation de la documentation WSDL wsdl doc, vu precede mment. 

Ces outils offrent toutes les possibilites de generation envisageables et peuvent etre utilises de 
maniere tres simple, en ligne de commande, en dehors d'environnements de developpement plus 
consequents et parfois moins maniables. 

La boite a outils WSTK (Web Services Toolkit) dTBM est maintenant disponible en version 3.3 a 
l'adresse http://www.alphaworks.ibm.com/tech/webservicestoolkit. 



Generer un squelette de service a partir d'une description 

Le pivot que constitue un fichier de description de services Web WSDL peut aussi etre mis a contri- 
bution pour realiser la generation d'un squelette d' implementation de service dans differentes tech- 
nologies (skeleton). 
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Cape Clear CapeStudio 3.0.1 

Si Ton prend comme point de depart le projet Transfer_WAS cree precedemment dans Fenvironne- 
ment CapeStudio, qui ne comporte pour 1' instant que le fichier WSDL genere et le fichier archive 
WSAR de deploiement a destination de la plate-forme d' execution CapeConnect, il est possible de 
generer une implementation de serveur EJB par exemple. 



Figure 13-20 

Projet Transfer_WAS 
- CapeStudio. 



9 Transfer WAS.csp - CapeStudio Developer Center 



Project Design Develop Integrate Deploy Help 



nl*l 



^e* $ 



o 

CapeStucia 



:-; C3< Transfer_WAS 

□ C:\CapeCleartPrajects\Transfer_WASITransfer_WAS.wsdl 

•g C:\CapeCleartProjects\TransferJ'VASVT'ransfer_WAS.wsar 

£J Server Implementation 

CJ< EJB Server Implementation 

[J Java Client 

[J Web Client 

£J Visual Basic Client 

£J Transformation 



Pour ceci, nous allons utiliser le menu Develop/Generate EJB Server. . . II est egalement possible d'utili- 
ser un autre outil : WSDL Assistant de CapeStudio, qui offre d'autres possibilites comme acceder a 
partir d'un annuaire UDDI prive de CapeConnect au modele WSDL prealablement publie par exemple. 



Figure 13-21 

Choix des options 
de generation 
du serveur EJB. 



Transfer WAS.wsdl - Generate EJB Server 



WSDL File: 



C:\Capeci8artProl8itelTranBfer_WA8lTransfer_WAS.wsdi 



Output Directors*: 



C:\CapeClear\Projects\Transfer_WAS\ejbsetver 



CapeConnect Map File: 



Generate 



Package Name: | Transfer_WAS 

Implementation File: | 

Required Libraries: 



Application Server — 

® WepLogic O iPlanet O Oracle 91 
GUID: 



fl{1 2fd2a22-6bcf-1 1 d5-8fD3-00b0d0 



^Jfljj<| 



Browse.. 



Browse.. 



Browse.. 



Generate 




Cancel 
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L'ecran de generation presente un certain nombre de parametres par defaut qui peuvent etre modifies 
et/ou completes. Ainsi, il est possible de specifier des librairies requises pour le fonctionnement du 
serveur EJB ou bien le type de serveur d' application cible et notamment le GUID (Global Unique 
Identifier) de l'EJB genere si le choix se porte sur un serveur iPlanet. 

Dans notre exemple, les options par defaut sont suffisantes et done maintenues. Apres utilisation du 
bouton Generate, le repertoire de generation (Output Directory) comprend des sous-repertoires qui 
contiennent l'ensemble des fichiers generes par Fassistant : 

• les sources et les classes Java qui correspondent aux standards de la specification EJB ; 

• les fichiers JAR correspondants ; 

• le descripteur de deploiement. 

Le descripteur de deploiement ejb-jar.xml du composant EJB genere par CapeStudio se presente 
comme suit : 

<?xml version="1.0"?> 

<!D0CTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc. //DTD Enterprise JavaBeans 1.1// 

*»EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_l_l.dtd'> 

<!-- 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: ejb-jar.xml 

Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 
--> 
<ejb-jar> 

<description>REPLACE WITH APPROPRIATE DESCRIPTION</description> 

<!-- 

Contains the declarations of one or more enterprise beans. 

--> 

<enterprise-beans> 



<!- 



Declares a session bean 



--> 
<session> 

<description>REPLACE WITH APPROPRIATE DESCRIPTION</description> 
<display-name>Transfer_WAS.TransferBinding</display-name> 
<ejb-name>Transfer_WAS.TransferBinding</ejb-name> 
<home>Transfer_WAS.TransferBindingHome</home> 
<remote>Transfer_WAS.TransferBinding</remote> 
<ejb-class>Transfer_WAS.TransferBindingBean</ejb-class> 
<session-type>Stateless</session-type> 
<transaction-type>Container</transaction-type> 
</session> 
</enterprise-beans> 
<!-- 

Contains application assembly information. 
--> 
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<assembly-descriptor> 

<container-transaction> 
<method> 

<ejb-name>Transfer_WAS.TransferBinding</ejb-name> 
<method-name>*</method-name> 
</method> 

<trans-attribute>Required</trans-attribute> 
</container-transaction> 
</assembly-descriptor> 
</ejb-jar> 

La classe d' implementation du serveur EJB (skeleton) se presente ainsi : 

/** 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: Trans ferBindingServer. Java 

Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 
*/ 
package Transfer_WAS; 

/** 

Skeleton Server Implementation - TransferBindingServer 

*/ 

public class TransferBindingServer 

implements TransferBindingServerlnterface { 

public float getBalancetint argO, Java. lang. String argl) 
throws Java. rmi . RemoteException { 

System. out. printlnCCTransferBindingServer] - getBalance") ; 
return (float)O.O; 
1 

public void transferFundsO'nt argO, int argl, float arg2, 
Java. lang. String arg3) throws Java. rmi .RemoteException { 

System. out. println( "[TransferBindingServer] - transferFunds" 



Les methodes de la classe generee ne demandent plus qu'a etre completees pour donner plus de 
consistance au serveur ainsi produit. 

Le session bean (stateless) EJB genere est le suivant : 

/** 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: TransferBindingBean. Java 

Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 
*/ 
package Transfer_WAS; 
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I** 

Skeleton Implementation - TransferBindingBean 

*/ 

public class TransferBindingBean 

implements javax.ejb.SessionBean { 

TransferBindingServer _impl = new TransferBindingServert ) ; 
public float getBal anceO'nt argO, Java. lang. String argl) 
throws java.rmi .RemoteException { 

return _impl .getBal ance ( argO, argl ); 
} 
public void transferFundsd'nt argO, int argl, float arg2, 

Java. 1 ang. String arg3) throws java.rmi .RemoteException { 
} 

public void ejbCreateO { 
) 

// inherited from javax.ejb.SessionBean 
public void ejbActivate( ) ( 
} 

public void ejbPassivate( ) { 
} 

public void setSessionContext(javax.ejb.SessionContext ctx) { 
) 

public void ejbRemoveO { 
} 
} 

L'interface locale {Home Interface) de l'EJB se presente comme suit : 

/** 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: TransferBindingHome. Java 

Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 
*/ 

package Transfer_WAS; 
/** 

Home Interface - TransferBindingHome 
*/ 

public interface TransferBindingHome 
extends javax.ejb. EJBHome { 

public TransferBinding createO 

throws javax.ejb. Create Except ion, java.rmi .RemoteException; 



) 
L'interface distante {Remote Interface) de l'EJB est ainsi genere : 

/** 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: TransferBinding. Java 

Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 
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*/ 

package Transfer_WAS; 

/** 

Remote Interface - TransferBinding 
*/ 

public interface TransferBinding 
extends javax.ejb. EJBObject { 

public float getBal anceO'nt argO, Java, 
throws java.rmi .Remote Except ion; 



ang. String argl) 



public void transferFunds(int argO, int argl, float arg2, 
Java. lang. String arg3) throws java.rmi .RemoteExcepti on; 
} 

Enfin, 1' interface du serveur implementee par le squelette est la suivante : 

I** 

Generated by Cape Studio WSDL Assistant 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 

http://www.capeclear.com/products/capestudio 

File: Trans ferBindingServer Interface. Java 
Creation Date: ven., mai. 10, 2002 at 23:31:50 CET 

*/ 

package Transfer_WAS; 

/** 

Server I nterfacelnterf ace 
*/ 



TransferBindingServer Interface 



public interface TransferBindingServerlnterface { 

public float getBalancetint argO, Java. lang. String argl) 
throws Java. rmi . RemoteExcepti on; 

public void transferFunds(int argO, int argl, float arg2, 
Java. lang. String arg3) throws java.rmi .RemoteException; 



Nous disposons maintenant d'un serveur EJB complet qui peut a son tour etre deploye et atteint via 
le service Web precede mment deploye et reconfigure pour acceder au nouveau serveur EJB. 



Figure 13-22 

Squelette de serveur 
EJB genere par 
CapeStudio. 
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Generer un client de test a partir d'une description 

Une derniere possibility est offerte d'utiliser le fichier WSDL pour generer un client de test du service 
Web dans differentes technologies. 

Nous allons illustrer cette capacite a travers differents outils. 

Cape Clear CapeStudio 3.0.1 

Avec toujours comme point de depart le projet Transfer_WAS (voir figure 13-20) cree precede mment 
dans l'environnement CapeStudio, qui ne comporte que le fichier WSDL genere et le fichier archive 
WSAR de deploiement a destination de la plate-forme d' execution CapeConnect, il est possible de 
generer differents clients de test : 

• un client Java ; 

• un client Web ; 

• un client Visual Basic. 

Pour generer un client Web par exemple, nous pouvons utiliser le menu Develop/Generate Web 
Client... 



Transfer WAS.wsdl - Generate Web Client 



WSDL File: 



Output Directory: 



C AC a p e C I e a r\P ro j e ctsVTra n sfe i _VVASV#e bclient 



_lD|x| 



C ACap aCle arlProja cts'iTra n 8 fe rJNASlTra n sfe r_WAS ,ws d I 



Browse... 



Generate — 

□ Generate Client Authentication 
Package Name: 
JSP Application Name: 
Indentation for Nested HTML Tables 






|"Transfer_ 


.WAS 


|"Transfer_ 


_WAS 


|10 


I 



Generate 




Cancel 



Figure 13-23 

Choix des options de generation du client Web de test. 



Un clic sur le bouton Generate provoque la generation d'une « mini-application Web » au sens de la 
specification JSP (JavaServer Pages) de la plate-forme J2EE. 

Pour etre utilisee, cette application doit etre deployee via le menu Deploy /Deploy Web Client. . . 



Principes de mise en oeuvre 

Chapitre 13 



Figure 13-24 

Choix des options 

de deploiement 

du client Web de test. 



Transfer WAS.war - Deploy Web Application 



r WAR File 

Ic^CapeCI 



C :IC a p e C I e a rlP ro j e ctsVTra n sfe r_WAS\we b c I i e nt\l i MTra n sfe r_WAS .war 



CapeConnect needs to be restarted to make this Web application available. 
® Restart CapeConnect now. 

O Restart CapeConnect later. 



Existing Web Application Directory 

An existing expanded directory forthis Web Application 

needs to be deleted before the servlet engine can initialise this version. 

Unchecking this means you will need to delete it manually. 

Delete existing Web Application Directory ? 



OK 




Cancel 



Le deploiement du fichier WAR (Web Archive) du client de test necessite 1' arret et le redemarrage de 
la plate-forme d' execution CapeConnect, operation qui peut etre differee si necessaire. Une fois le 
serveur CapeConnect redemarre et le client Web de test installe, celui-ci peut etre mis en oeuvre via le 
studio a partir du menu Deploy/Run Web Client. 
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Readme forTransfer_WAS web application. 

This web application allows you to invoke operations against the web service specified in the 
WSDL file. 

• Click on the desired operation on the left hand frame. 

• A request page will be displayed in this frame. 

• Enter input parameters and click on the "invoke" button. 

• The response will be displayed in the frame below. 

This Web Application was generated by Cape Studio WSDL Assistant 

Creation Date: ven., janv. 11, 2002 at 00:43:36 CET 

WSDL Assistant Copyright (c) 2001,2002 Cape Clear Software Ltd. 



zi 



^] Termine 



$ Internet 



Figure 13-25 

Client Web de test genere par V assistant CapeStudio. 
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Si Ton cherche a obtenir le solde n° 123456 gere par le serveur EJB sur WebSphere, via le service 
Web precedemment deploye sur le serveur CapeConnect, il suffit d'invoquer la methode getBal ance, 
de fournir le numero de compte, puis d'invoquer le service Web. 
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Figure 13-26 

Invocation du solde du compte n '123456 de WebSphere via CapeConnect. 



Nous obtenons le solde de 16 000 € que nous avions laisse sur ce compte lors du precedent transfert 
en provenance du compte n°654321 egalement gere sur le serveur WebSphere. Nous avons mainte- 
nant besoin d'effectuer un nouveau transfert de 5 000 € toujours a partir de ce meme compte. 

Comme on peut le verifier sur ce dernier ecran (figure 13-27), l'operation de transfert entre comptes 
sur le serveur WebSphere 4.0 s'est bien deroulee. 

Nous disposons done maintenant d'un client de test qui peut etre utilise a tout moment pour verifier 
le bon fonctionnement du service Web deploye en frontal sur le serveur CapeConnect ou celui du 
serveur EJB WebSphere qui opere a l'arriere-plan. Le code genere peut etre eventuellement reutilise 
dans le cadre de l'application Web susceptible d'utiliser ce nouveau service Web. 
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Figure 13-27 

Invocation du transfert de compte a compte de WebSphere via CapeConnect. 



WebService Browser de GotDotNet 

Outre le service Web WsdlVerify de cette meme communaute, que nous avons deja utilise dans le 
chapitre 10 « Decrire un Service », et qui aurait pu figurer dans cette section pour sa capacite a gene- 
rer un proxy-service en langage C#, un autre outil presente des caracteristiques interessantes et peut 
etre utilise pour generer un client en VBScript. II s'agit du WebService Browser, accessible a http:// 
apps.gotdotnet.com/xmltools/WsdlBrowser. 

L'utilisateur fournit une URL de fichier WSDL. Cette interface Web peut egalement lire un fichier 
WSDL localement sur la machine si le navigateur Internet lui en laisse la possibilite. En dernier 
recours, l'utilisateur peut proceder a un copier/coller pour remonter son fichier WSDL local. II est 
ensuite possible d'obtenir une generation de proxy-service en langage VBScript qui peut etre imme- 
diatement execute, toujours si les droits sont suffisants ou recupere par une autre operation de copier/ 
coller. 
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De meme, il est possible d'invoquer un service Web sans que sa description WSDL soit visible sur 
Internet. II peut etre interessant de tester de l'exterieur du pare-feu local un service Web en cours de 
developpement par exemple. II faut cependant noter que seules l'analyse syntaxique et la generation 
de la requete SOAP sont traitees sur le serveur distant, F invocation proprement dite du service reste 
locale via une requete POST. 
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Figure 13-28 

Invocation d'un service Web a partir du WebSenice Browser de GotDotNet. 



Si nous reprenons notre exemple precedent d' application de gestion de comptes via des objets EJB 
sous WebSphere 4.0, exposee sous forme d'un service Web publie sur la plate-forme d' execution 
CapeConnect, il est possible, apres analyse syntaxique du document WSDL prealablement commu- 
nique a cet outil, d'invoquer le solde du compte n° 123456 en modifiant simplement le texte de la 
requete SOAP (champ Request sample de l'ecran de la figure 13-28), puis en cliquant sur le bouton 
POST request. 

Le resultat de cette invocation par 1' intermediate du protocole SOAP/HTTP est quasi instantane et 
s'affiche dans la fenetre du bas : il s'agit bien d'un solde de 21 000 €. 
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Figure 13-29 

Resultat de {'invocation du service Web a partir du WebService Browser de GotDotNet. 

All final, nous avons done demande au serveur de GotDotNet, qui est une configuration Microsoft- 
IIS/5.0 sous Windows 2000 (d'apres Foutil de Netcraft : What's that site running ?, http:// 
uptime.netcraft.com/up/graph), de preparer une requete SOAP qui permette ensuite au navigateur d'invo- 
quer un serveur Java CapeConnect qui, a son tour a envoye une requete au serveur EJB WebSphere. 
Et la reponse finale a ete relayee dans F autre sens tres rapidement. 

Le proxy-service VBScript ainsi genere se presente ainsi : 

Dim sc 

set sc = CreateObjectCMSSOAP.SoapClient") 

' 'sc.Cl i en t Property ("Connector Prog ID") = "MSSOAP.TraceConnector.l" 

wsdl = "C:\CapeClear\Projects\Transfer_WAS\Transfer_WAS.wscn " 
sc.mssoapinit wsdl 
dim result, v, vO, vl 

vO = "0" 

vl = "string" 



Les plates-formes operationnelles 

Thoisieme Partie 



' 'On Error resume next 
v = sc.getBalance(vO, vl) 



result = CStr(v) 

''result = result + sc.ConnectorPropertyCTRACE") 

MsgBox result 

Si la valeur de la variable vO est remplacee par 123456, on obtient a nouveau le solde du compte 
n° 123456 sur le serveur WebSphere. 

Conclusion 

Ce chapitre nous a permis d'evaluer le nouveau saut technologique auquel nous devons nous prepa- 
rer. De nouvelles perspectives sont ouvertes par 1' emergence des technologies issues du langage 
XML et plus particulierement des services Web. 

Pour autant, ces nouvelles technologies, dont les promoteurs cultivent avec opiniatrete l'indepen- 
dance vis-a-vis des plates-formes materielles et logicielles, des modeles de composants et des langa- 
ges de programmation, ont pour ambition de permettre une recuperation des patrimoines applicatifs 
des entreprises sans intrusion forte dans ces systemes operationnels, comme cela a pu etre le cas dans 
le passe avec les architectures COM/DCOM, CORBA et EJB. 

Le choix entre les differentes plates-formes proposees par les editeurs de systemes d' exploitation et 
les constructeurs ne sera plus la premiere preoccupation des decideurs comme cela reste encore trop 
souvent le cas aujourd'hui, mais passera au second plan, derriere des decisions guidees par les riches- 
ses de Foffre en termes de solutions fonctionnelles et de services proposes par l'une ou Fautre de ces 
plates-formes. 

Cependant, il n'en reste pas moins vrai que, pour faire echo a « l'exuberance des marches finan- 
ciers » de ces dernieres annees, selon la desormais celebre formule d'Alan Greenspan, l'exuberance 
simultanee des marches du traitement de l'information et plus specialement d'Intemet conduit des 
aujourd'hui a une necessite de rationalisation des investissements des entreprises, comme le consta- 
tent deja certains cabinets d'etudes prospectives et strategiques. 

Dans ces nouvelles conditions de marche, deux plates-formes sont particulierement susceptibles de 
rafler la mise : le framework Java/J2EE et son challenger .NET. Le potentiel de ces deux environne- 
ments est etudie dans les deux prochains chapitres. 

Le chapitre suivant fait le point sur les evolutions concernant le navigateur Internet qui, lui aussi, 
subit la pression des changements introduits par 1' emergence des technologies XML. 

Enfin, le dernier chapitre de cette partie s' attache a mettre en evidence les difficultes qui subsistent en 
termes d'interoperabilite du fait de certaines zones d'ombre dans les specifications, difficultes 
auxquelles les acteurs majeurs et les principaux auteurs de ces specifications ont oppose une forte 
volonte d'organisation via la creation recente d'un consortium industriel en charge du respect des 
specifications et de l'interoperabilite des implementations. 
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La communaute Java, malgre un retard initial de ses representants les plus officiels, excepte IBM, 
participe desormais activement a la definition et a la mise en place des nouvelles infrastructures Inter- 
net fondees sur la technologie des services Web. Ce chapitre est destine a illustrer cette situation et a 
presenter un panorama des technologies disponibles. 

La premiere partie de ce chapitre est dediee a F identification des principaux acteurs qui influencent 
les efforts de la communaute Java/J2EE dans la production et la commercialisation de nouvelles 
technologies adaptees a la prise en compte des nouveaux besoins. 

Les parties qui suivent sont consacrees a une approche de Foffre marketing et commerciale des prin- 
cipaux editeurs de produits specialises dans la conception, le developpement, les tests, le deploie- 
ment et 1' exploitation de services Web en technologie Java. 

Enfin, la derniere partie du chapitre est destinee a donner au lecteur un ensemble de liens vers des 
sites de references et de ressources qui lui permettront de plonger au cceur de l'offre deja tres vaste 
proposee aux entreprises qui s'appuient sur la plate-forme Java/J2EE. Cette presentation de l'offre 
dans Fenvironnement Java n'est pas exhaustive. Nous sommes ici dans un domaine en ebullition ou 
les editeurs apparaissent et disparaissent rapidement et ou le phenomene de concentration a deja 
debute. Pour un panorama tres detaille de l'offre, se referer aux actualites de sites de ressources 
specialises signales en fin d'ouvrage. 

Principaux acteurs 

L'offre technologique disponible dans l'ecosysteme Java/J2EE est a l'heure actuelle deja tres diversi- 
fied. Cette richesse trouve son origine dans differents evenements qui se sont produits dans la (tres) 
courte histoire des services Web : 

• implication des le debut d'un des acteurs majeurs de la communaute Java/J2EE : IBM ; 



Les plates-formes operationnelles 

Troisieme Partie 

• experience anterieure des nouveaux concepts mis en avant par ces technologies de la part 
d'un autre acteur tres important de cette meme communaute : Hewlett-Packard ; 

• hesitations initiales de Sun Microsystems et done retard important dans 1' activite de specifi- 
cation de la communaute JCP affiliee ; 

• forte implication des acteurs de l'Open Source dont la communaute Apache et divers projets 
SourceForge ; 

• apparition de plusieurs start-ups pointues qui s'engouffrent dans la breche et introduisent des 
implementations originales des premieres specifications. 

IBM : I'initiateur 

Nous avons vu dans les chapitres precedents qu'IBM a participe a F elaboration des trois specifica- 
tions qui constituent le socle normatif des services Web. Parallelement a cette activite de specification, 
IBM a travaille au developpement d' implementations en Java de ces specifications. Cette activite 
s'est traduite par l'apparition des paquetages SOAP4J, WSDL4J et UDDI4J. 

Ces differentes implementations ont rapidement ete integrees dans des boites a outils plus conse- 
quentes telles que le WSDL Toolkit (voir http://www.alphaworks.ibm.com/tech/wsdltoolkif), un ensemble 
d'outils permettant de generer du code client et/ou serveur a partir d'un document WSDL, a son tour 
rapidement absorbe dans une autre plate -forme encore plus importante : le Web Services Toolkit, ou 
WSTK (voir http://www.alphaworks.ibm.com/tech/webservicestoolkit). 

Ce dernier ensemble logiciel evolue toujours tres regulierement et integre des implementations et de 
nouvelles specifications, qui correspondent, soit a des propositions d'origine strictement IBM 
comme HTTPR (Reliable Hypertext Transfer Protocol) ou WSFL (Web Services Flow Language), 
soit a des implementations de specifications qui sortent du cadre dTBM comme WS-Security (Web 
Services Security). 

Parallelement a cette intense activite de recherche et developpement, IBM a egalement precede a 
l'elaboration de son futur environnement de developpement oriente services Web. Cet environne- 
ment, nomme XML and Web Services DE, auparavant disponible sur le site d' alpha Works (http:// 
www.alphaworks.ibm.com/tech/wsde) est aujourd'hui integre dans les produits commerciaux WebSphere 
Studio Application Developer (WSAD) et WebSphere Studio Site Developer (WSSD). Les deve- 
loppeurs ont ainsi pu, longtemps avant la sortie officielle de ces produits, se familiariser avec ce 
nouvel environnement de developpement issu des travaux de la communaute Eclipse (voir http:// 
www.eclipse.org). 

Hewlett-Packard : le visionnaire 

Quelque temps avant l'apparition des specifications SOAP, WSDL et enfin UDDI, Hewlett-Packard 
proposait deja un produit, e-Speak, concu des 1995 dans les laboratoires HP et commercialise des 
1999 par une structure commerciale dediee creee l'annee precedente. II integrait deja tous les grands 
concepts aujourd'hui devenus populaires sous l'appellation de services Web. 

Malheureusement, comme tous les produits qui ont ete introduits trop tot sur leur marche, celui-ci n'a 
pas echappe a la regie generate, et Hewlett-Packard a ete contraint de le refondre en s'appuyant sur 
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les nouvelles specifications plus ouvertes et sur 1' implementation du serveur d' applications Java de 
Bluestone, rachete dans l'intervalle. 

Cependant, cette etape initiale a permis aux equipes de Hewlett-Packard de prendre une enorme 
avance dans la manipulation de ces nouveaux concepts et de reconfigurer son offre initiale dans une 
nouvelle offre, laquelle a ete concue tres rapidement. 

Sun Microsystems : un retard inexplicable 

Le chapitre precedent a mis en lumiere le retard pris initialement par Sun Microsystems dans la prise 
en compte de la technologie XML par la plate-forme Java. En effet, l'arrivee de la premiere imple- 
mentation d'un analyseur syntaxique XML (Project X) dans l'offre de Sun, debut 1999, etait tardive 
par rapport a celle d'IBM qui disposait deja d'un analyseur (XML4J) lors de la standardisation 
d'XML en 1998. C'est d'ailleurs la seconde evolution de ce dernier analyseur, donne par IBM a la 
communaute Apache fin 1999, qui va etre introduite dans le SDK 1.4, via le nouveau mecanisme des 
« standards endosses ». Signalons qu'entre -temps, F analyseur de Sun, devenu Crimson a, lui aussi, 
fait l'objet d'un don a la communaute Apache. 



Endorsed Specifications et Endorsed Standards 

Les specifications « endossees » (ou « approuvees ») correspondent a des specifications realisees par des grou- 
pes exterieurs a la communaute JCP, qui pilote le developpement de la plate-forme J2EE depuis 1995. En effet, 
jusque tres recemment (1999), toutes les specifications relatives a cette plate-forme etaient congues et publiees 
par le JCP. Depuis I'annee 2000, cela n'etait plus possible et il devenait necessaire de prevoir un mecanisme par 
lequel une specification JCP reconnaissait s'appuyer sur une specification externe officiellement reconnue. Le 
probleme s'est pose justement au sujet du developpement de I'analyseur syntaxique Crimson. Celui-ci correspon- 
dait a I'implementation de reference de la JSR 5, finalisee le 21 mars 2000 : Java API for XML Parsing (JAXP) . 
Cette specification JCP s'appuyait sur des specifications du W3C (recommandations XML 1.0, XML Namespa- 
ces 1.0 et Document Object Model Level 1) ainsi que la specification Simple API for XML Parsing (SAX). 
Depuis la sortie du SDK J2SE 1 .4 de Sun Microsystems, la notion de standards approuves {endorsed standards) 
est egalement apparue. Un standard approuve correspond a une API Java definie via un autre processus de speci- 
fication que le JCP. A cette prise en compte d'implementations Java exterieures, est associe un mecanisme d'inte- 
gration de nouvelles versions de ces implementations (override mechanism) selon un calendrier bien evidemment 
different de celui des evolutions du SDK (voir http://java.sun.eom/j2se/1.4/docs/guide/standards). Cette prise en 
compte s'effectue notamment par le biais de I'utilisation de la nouvelle propriete systeme Java. endorsed. dirs 
ou, a defaut, le repertoire <java-home>\lib\endorsed (Windows) ou <java-home>/lib/endorsed (Solaris et Linux) du 
SDK. Par ce mecanisme, il est ainsi possible de prendre en compte de nouvelles versions des analyseurs syntaxi- 
ques Xerces ou Xalan de la communaute Apache, par exemple. 



Ce retard initial est tres etonnant, d'autant que le responsable du groupe de standardisation XML au 
W3C etait un architecte de Sun : Jon Bosak. In fine, ces tergiversations de Sun, quant a la prise en 
compte d'XML et des technologies derivees dans la plate-forme Java, ont fini par devenir tres visi- 
bles et poser des problemes a d'autres acteurs majeurs de la communaute Java, ce qui s'est traduit par 
une proliferation d'implementations proprietaries (voir notamment les produits Xalan et Xerces 
d'IBM, devenus entre-temps des references et donnes depuis a la communaute Apache). Ce retard 
initial n'a pu etre rattrape depuis et constitue actuellement un handicap certain dans la prise en charge 
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des services Web par la plate-forme Java, ceux-ci s'appuyant egalement sur des specifications deri- 
vees d'XML. 

Cependant, en 2002, apres avoir ete tres fortement critique pour ses hesitations et sa lenteur, Sun 
semble avoir pris conscience de la situation et s'etre decide a combler son retard. Cela s'est traduit 
notamment par la prise en compte de nouvelles JSR dediees aux services Web par le JCP, tres rapide- 
ment suivie par Fannonce de nouvelles implementations de references correspondantes, destinees a 
etre integrees dans la plate-forme Java, a partir de la version J2EE 1.4 qui devrait etre disponible 
durant Fete 2003. 

La communaute Open Source : accelerer le mouvement 

Pour mener de front tous ses developpements, IBM a largement fait appel a la communaute Open 
Source. 

Apres le transfert a la communaute Apache, en 1999, de son analyseur syntaxique XML4J (voir http:/ 
/www.alphaworks.ibm.com/tech/xml4j), devenu depuis Xerces, puis celui du transformateur XSL 
LotusXSL (voir http://www.alphaworks.ibm.com/tech/LotusXSL), devenu Xalan, IBM a aussi annonce le 
transfert (voir http://www-916.ibm.com/press/prnews.nsf/jan/63E751E6E605F071852568F10070DAF8) vers la 
communaute Apache, en juin 2000, de 1' implementation SOAP for Java : SOAP4J (voir http:// 
www. alphaworks. ibm. com/tech/soap4j) . 

Ces differents produits ont continue a evoluer et sont maintenant disponibles sous le regime de la 
licence Apache. lis en sont deja a la deuxieme generation : l'analyseur syntaxique XML Xerces 2 est 
deja disponible et Axis, le successeur de SOAP4J, est deja disponible en version 1.0 ou dans le Web 
Services Toolkit (WSTK) dTBM depuis la version 2.2 de ce dernier. Axis devrait d'ailleurs faire son 
apparition dans WebSphere 5.0. 

Par ailleurs, IBM poursuit les developpements, sous le regime des licences publiques communes ou 
IBM, de son API Java UDD4J d'acces, cote client, aux annuaires UDDI (voir http:// 
oss.software.ibm.com/developerworks/projects/uddi4j) et de son API WSDL4J de manipulation de docu- 
ments WSDL (voir http://www-124.ibm.com/developerworks/projects/wsdl4j). Cette implementation est inte- 
gree dans de nombreux produits, dont le Registry Composer de Hewlett-Packard par exemple. 

Enfin, nous avons vu le role important joue par la communaute Eclipse, dont la creation a ete suscitee 
par IBM. Cette communaute a ete dotee d'un code source d'origine IBM d'une valeur estimee a 
quarante millions de dollars. Le travail de cette communaute a permis ensuite a IBM de fournir une 
nouvelle generation d'environnements de developpement, integres dans un framework d' atelier logiciel 
generique, en un temps record. 

Les start-ups : des opportunites a saisir 

De nombreuses societes specialises se sont creees tres rapidement dans la mouvance des services 
Web. Celles-ci ont ete constitutes, pour la plupart, par des fondateurs qui ceuvraient dans des societes 
dont le domaine d'activite s'exercait deja dans les systemes distribues. Lune de ces entreprises a ete 
notamment tres prolifique : il s'agit de IONA Technologies. Deux groupes d'anciens employes ont 
essaime pour creer deux societes distinctes specialisees dans les plates-formes de services Web : il 
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s'agit de Cape Clear, basee a Dublin, et de Shinka Technologies, etablie a Berlin. IONA Technologies 
propose elle aussi un produit dedie a ce marche. 

Ces nouvelles societes ont vu Fopportunite de s'engouffrer dans cette niche appelee a devenir un tres 
grand marche selon les etudes de divers cabinets de recherche et d' analyse strategique. Elles ont aussi 
profite de rimmobilisme de certains acteurs majeurs de la communaute Java/J2EE, allant meme 
jusqu'a developper leurs propres API, comme The Mind Electric l'a fait avec son produit Glue, par 
exemple. 

L'implementation SOAP de reference : Apache SOAP4J 

L' organisation Apache fait evoluer a l'heure actuelle la principale implementation de SOAP en envi- 
ronnement Java. Cette implementation est referencee comme un sous-projet du projet XML de 
1' organisation. Le point d'entree de ce sous-projet est situe a Fadresse http://xml.apache.org/soap/ 
index.html. Cette implementation remplace F implementation SOAP4J (SOAP for Java) d'origine IBM, 
dont elle est issue, anciennement disponible sur le site alphaWorks dTBM (http://www.alphaworks.ibm 
.com/tech/soap4j). 

Celle-ci est en realite reprise dans la plupart des configurations de produits de services Web fournis 
par de nombreux editeurs. La version actuellement la plus utilisee, telechargeable depuis mai 2001, 
est la version 2.2 (voir http://xml.apache.org/dist/soap). Une nouvelle version 2.3 est proposee en tele- 
chargement depuis mai 2002 (elle prend en compte la specification XML Schema 2001 notamment, 
et comporte de nombreuses ameliorations). Cette derniere version, legerement amendee en 2.3.1, est 
finalement disponible depuis juin 2002. 

Analyseur syntaxique XML Xerces 

Cette implementation est la plupart du temps associee au parser XML Xerces de la meme organisa- 
tion. Xerces est egalement un sous-projet du projet XML de l'organisation Apache, situe a http:// 
xml.apache.org/xerces-j/index.html. 

Les versions actuellement telechargeables sont les versions 1.4.4 et 2.2.1 (voir http://xml.apache.org/dist/ 
xerces-]). La version 1.4.4 constitue la derniere version de la premiere generation de l'analyseur 
syntaxique. La releve est done en cours avec Farrivee de la seconde generation et de la version 2.2.1. 

Container Servlets/JSP Tomcat 

Un certain nombre de produits de services Web proposes sont par ailleurs associes au serveur Servlet/ 
JSP Tomcat d' Apache, conjointement avec le parser Xerces et F implementation SOAP d' Apache. 
Les ressources associees a ce serveur sont accessibles sur le site du projet Jakarta (http:// 
jakarta.apache.org). 

Ce serveur est en cours d' integration dans la version 1.4 de la plate-forme Java 2 Enterprise Edition, en 
tant qu' implementation de reference des specifications Servlets et JavaServer Pages, et est egalement 
integree dans le Web Services Pack de Sun. 
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Serveur SOAP Axis 



Enfin, un nouveau sous-projet XML, nomme Axis, est en cours de developpement et la version 1 .0 
est disponible depuis le 7 octobre 2002. Ce projet se presente comme une suite de 1' implementation 
actuelle d' Apache (SOAP 2.3.1) : il est egalement parfois appele SOAP 3.0. 

Cette nouvelle version est une reecriture totale et est concue autour d'un modele de streaming qui 
exploite done plutot 1' API SAX que F API DOM des analyseurs syntaxiques XML. II faut egalement 
noter la prise en charge de la specification JMS en tant que protocole de transport utilisable dans la 
version finale d'Axis 1.0. 

Les ressources de ce dernier projet sont accessibles a http://xml.apache.org/axis/index.html. 

L'offre d'IBM : Dynamic e-business 

IBM est historiquement le premier acteur majeur du camp Java a s'etre interesse aux services Web. 
Son action s'est concretisee par sa participation au processus de specification des fondamentaux : 

• le protocole (Simple Object Access Protocol) SOAP 1.1 (voir http://www.w3.org/TR/SOAP et les 
chapitres 7, 8 et 9) ; 

• le langage de description de services (Web Services Description Language) WSDL 1 . 1 (voir 
http://www.w3.org/TR/wsdlet chapitre 10) ; 

• la specification de UDDI 1.0 (Universal Description, Discovery and Integration) et 2.0 (voir 
http://www.uddi.org et chapitres 11 et 12). 

Parallelement a cette action initiale de specification et de normalisation, IBM a travaille a l'implementa- 
tion Java de ce triptyque de specifications. De nombreuses versions d' implementations initiales, destinees 
aux developpeurs Java, ont ete publiees sur le site d'alphaWorks (voir http://www.alphaworks.ibm.com) : 
XML and Web Services Development Environment, Web Services ToolKit, SOAP for Java, UDDI 
Registry, Lotus Web Services Enablement Kit, WebSphere SDK for Web Services, etc. 

Annee 2001 : an nonces de nouveaux produits 

En matiere de produits commerciaux, IBM a precede a de nombreuses annonces des le debut de 
1' annee 2001. On peut notamment citer : 

• L'annonce de la disponibilite de l'environnement de developpement WebSphere Technology 
for Developers (voir http://www-4.ibm.com/software/webservers/p010314a.html) effectuee le 14 mars 
2001 : il s'agit en fait d'une version WebSphere 4.0 Technology Preview qui introduit la 
compatibilite J2EE 1.2 et l'integration UDDI, SOAP et WSDL (disponible depuis le 31 mars 
2001 sur plate-forme Windows NT uniquement). 

• L annonce de la prochaine disponibilite de logiciels et de services d' infrastructure de produc- 
tion (voir http://www-4.ibm.com/software/solutions/webservices/pressrelease.htmi) adaptes aux services 
Web, effectuee le 14 mai 2001 : cette annonce presente les nouveautes suivantes : 

- WebSphere Application Server 4.0 (disponibilite annoncee : juin 2001) ; 
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- WebSphere Studio Technology Preview for Web services (disponibilite beta depuis juillet 
2001 et release en septembre 2001) : environnement de developpement, test et deploiement 
de services Web ; 

- WebSphere Business Integrator (disponibilite non specifiee) : implementation de SOAP 
sur MQSeries ; 

- DB2/XML Extender for DB2 7.2 (disponibilite de DB2 7.2) : prise en charge d'UDDI et 
de SOAP pour permettre l'acces aux donnees a des applications de services Web ; 

- Tivoli Manager for WebSphere Application Server (disponibilite non precisee) ; 

- Tivoli Web Services Manager (disponibilite non precisee) ; 

- Tivoli Secure Way Policy Director (disponibilite non precisee) ; 

- Lotus Web Services Enablement Kit (disponibilite fin deuxieme trimestre 2001) ; 

- integration possible de Web Services dans les produits existants : Domino Application 
Server, Domino Workflow, Knowledge Discovery System, Sametime, LearningSpace. 

• L'annonce de la disponibilite de la version 4.0 de WebSphere Application Server effectuee le 
30 mai 2001 (voir http://www-4.ibm.com/software/webservers/appserv/pr_version4.html) : cette annonce 
presentait egalement les nouveaux environnements de developpement associes dont Web- 
Sphere Application Server Developer Version 4.0, les nouvelles versions de WebSphere 
Studio et VisualAge for Java et une nouvelle generation d'outils de developpement destines a 
succeder aux produits WebSphere Studio et VisualAge for Java. Ce nouvel environnement 
WebSphere Studio Workbench est disponible sous Windows et Linux, en version beta depuis 
juillet 2001 via une diffusion initiale par 1' intermediate du programme PartnerWorld for 
Developers (http://www.developer.ibm.com/welcome/wstools/workbench.html). 

WebSphere Application Server 4.0 et 5.0 

En matiere de disponibilite des produits, le serveur d' applications WebSphere 4.0 est disponible (voir 
http://www-4.ibm.com/software/webservers/appserv) depuis le 30 juin 2001 en version Advanced Edition 
(Single User, Full Configuration ou Developer License). La version Enterprise Edition est apparue plus 
tard. La version Standard Edition, presente dans la version WebSphere 3.5, a disparu du catalogue. 

Tout comme la version WebSphere 3.5, la version 4.0 fait Fobjet de corrections et d' ameliorations 
constantes sous forme de fichiers correctifs unitaires (e-fixes) ou d' ensembles de fichiers correctifs 
(fixpaks) telechargeables. Celle-ci est actuellement disponible en version 4.0.3. 

Les developpeurs avances peuvent actuellement acceder a la nouvelle version WebSphere Techno- 
logy for Developers: il s'agit d'une WebSphere 5.0 Technology Preview (voir http://www7b. 
boulder.ibm.com/wsdd/downloads/wstechnology_tech_preview.html) qui introduit notamment la compatibilite 
J2EE 1.3 et la prise en compte de l'API JAXP definie par la communaute JCP. 

La version 5.0 de WebSphere est disponible depuis le 26 novembre 2002 (voir annonce http://www-3.ibm. 
com/software/info1/websphere/index.jsp?tab=news/ibmnews/pr112502&S_TACT=102BBW01&S_CMP=campaign). 
Contrairement aux habitudes dTBM, la disponibilite de cette version a ete reportee au-dela de celle 
des environnements de developpement, ce qui n'etait pas le cas jusqu'a maintenant (voir ci-apres). 
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Eclipse et WebSphere Studio (Application Developer et Site Developer) 

Les versions beta des produits WebSphere Studio Site Developer et WebSphere Studio Application 
Developer, issus de la technologie WebSphere Studio Workbench (voir http://www-4.ibm.com/software/ad/ 
workbench) ont ete disponibles sur le site PartnerWorld for Developers et telechargeables en disponibilite 
generate (toujours en version beta) sur le site d'IBM des septembre 2001. 

Le document http://www7b.boulder.ibm.com/wsdd/library/techarticles/0108_studio/studio_beta.html fournit des 
precisions sur ces nouveaux environnements et la parente avec les precedents environnements de 
developpement WebSphere Studio et VisualAge for Java. La version 4.0 de VisualAge for Java ne 
prend pas en charge les services Web, mais est livree en bundle avec la version beta de WebSphere 
Studio Application Developer. 

Les informations relatives au produit WebSphere Studio Application Developer (WSAD) sont dispo- 
nibles a http://www-3.ibm.com/software/ad/studioappdev. La version 5.0 de ce produit a ete annoncee fin 
2002 (voir annonce : http://www-3.ibm.com/software/ad/studioappdev/about/V5.html) et est actuellement 
disponible via le programme Passport Advantage. 

Les informations propres au produit WebSphere Studio Site Developer sont accessibles a http://www-3 
.ibm.com/software/ad/studiositedev. 

Annee 2002 : nouvelles specifications et nouveaux produits 

Apres F integration des technologies de base (SOAP, WSDL et UDDI) dans la quasi-integralite de ses 
produits, IBM a poursuivi et accelere ses efforts en 2002, a la fois dans le domaine des specifications 
et du cote des implementations et des produits. 

En ce qui concerne les produits, des serveurs d' applications de la version 5.0 de WebSphere sont arri- 
ves sur le marche. Cette nouvelle version illustre de maniere plus importante les echanges de plus en 
plus consequents qui s'operent entre IBM et les communautes Open Source, dont notamment la 
communaute Apache pour ce qui a trait aux technologies de base : integration de l'analyseur syntaxi- 
que XML de seconde generation Xerces 2 et de Fenvironnement d'execution SOAP Axis. 

Par ailleurs, la boite a outils laboratoire Web Services ToolKit, ou WSTK, (voir http://www.alphaworks 
.ibm.com/tech/webservicestoolkif) poursuit ses evolutions et continue a integrer de nouvelles implementa- 
tions et de nouvelles specifications : integration du moteur d'execution SOAP Axis, evolution de 
UDDI4J 1.0 vers la version 2.0, compatibilite avec Windows XP, etc. 

A cote de cet outil maintenant relativement ancien (dix versions depuis juillet 2000 a ce jour), est 
apparu un nouvel environnement nomme WebSphere SDK for Web Services (WSDK), operationnel 
sous les environnements d' exploitation Linux (distributions Red Hat et SuSe) et Windows (2000 et 
XP). Ce nouvel environnement est destine a repondre aux profils definis par Forganisation WS-I 
(pour en savoir plus sur cette organisation, se reporter au chapitre 17 « Le defi de Finteroperabi- 
lite »). II constitue done la reponse d'IBM a la problematique de Finteroperabilite que ce nouvel 
organisme prend en charge de maniere specifique. A ce titre, le WSDK evoluera done en adequation 
avec les evolutions des profils definis par le WS-I. 

Le WSTK peut s'appuyer sur le noyau du WSDK pour son propre fonctionnement. Tout comme le 
WSTK, le WSDK est en realite une boite a outils qui offre un environnement complet de developpe- 
ment et de tests de services Web, mais il n'est pas utilisable en tant qu' environnement de production. 
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Pour ce faire, les utilisateurs de ces environnements devront deployer les services Web ainsi produits 
sur les plates-formes d'execution adequates (serveurs d' applications WebSphere 4.0 ou5.0 par 
exemple). Les informations relatives ail WSDK sont disponibles a l'adresse http://www-106.ibm.com/ 
developerworks/webservices/wsdk. 

Ail chapitre des specifications, l'annee 2002 a egalement ete marquee par une activite de specifica- 
tion toujours tres intense, notamment par de nombreuses initiatives sur les technologies des couches 
superieures (gestion des processus et des conversations : voir chapitre 21) et transversales (securite, 
fiabilite, etc. : voir - chapitres 18, 19 et 20). 

L'annonce la plus importante a ete effectuee le 9 aoiit 2002, en commun avec BEA et Microsoft (voir 
annonce http://www.microsoft.com/presspass/press/2002/aug02/08-09BEAPR.asp). Cette annonce porte sur la 
production de trois nouvelles specifications dont l'objectif consiste a permettre la gestion de proces- 
sus et de transactions, fondes sur des services Web, a l'interieur d'une entreprise ou entre plusieurs 
partenaires. Cette annonce introduit done les nouvelles specifications suivantes : 

• BPEL4WS, ou Business Process Execution Language for Web Services : http://www- 
1 06.ibm.com/developerworks/library/ws-bpel ; 

• WS-Coordination, ou Web Services Coordination : http://www-106.ibm.com/developerworks/library/ws- 
coor; 

• WS-Transaction ou Web Services Transaction : http://www-106.ibm.com/developerworks/library/ws- 
transpec. 

Cette annonce a ete immediatement suivie, pour ce qui concerne IBM, de la sortie d'une implemen- 
tation de la premiere des trois specifications, publiee le meme jour sur le site alphaWorks : il s'agit de 
la technologie Business Process Execution Language for Web Services Java Run Time ou BPWS4J 
(voir http://www.alphaworks.ibm.com/tech/bpws4j). De meme, une nouvelle version du WSTK (3.2.1), rapi- 
dement remplacee par la version 3.2.2 et telechargeable depuis cette annonce, integre des demonstrations 
qui mettent en ceuvre ces trois specifications. 

Les efforts de normalisation de la communaute Java 

La communaute Java, a travers le processus JCP (Java Community Process) mis en place par Sun 
Microsystems, a la suite de deux tentatives avortees de normalisation du langage et de l'environne- 
ment d'execution Java, poursuit ses efforts de normalisation et controle ainsi son evolution. Les 
normes, issues de cette activite JCP, constituent bien entendu des normes de fait (de facto), et non pas 
de droit (de jure), dans la mesure ou elles ne sont pas endossees par une organisation interprofessionnelle 
prevue a cet effet comme le W3C par exemple. 

C'est notamment via ce processus JCP que sont decidees les evolutions des plates-formes de deve- 
loppement JDK (Java Development Kit) et d'execution JRE (Java Runtime Environment), ainsi que 
les plans devolution (roadmaps) associes. 

L'arrivee des premieres versions des specifications SOAP, WSDL et UDDI et surtout des premieres 
implementations proprietaries Java correspondantes s'est traduite par la necessite de prendre en 
compte ces evolutions et de mettre en place les processus de specification necessaires, afin de preserver 
l'universalite de la plate-forme Java. 
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Cette soudaine prise de conscience s'est illustree par Fannonce simultanee de la constitution de 
plusieurs demandes de specification Java JSR (Java Specification Request) destinees a prendre en 
charge ces evolutions. Ces JSR sont les suivantes : 

• JSR109 - Implementing Enterprise Web Services : http://www.jcp.org/jsr/detail/109.jsp ; 

• JSR1 10 -Java APIs for WSDL(JWSDL) : http://www.jcp.org/jsr/detail/110.jsp; 

• JSR03 1 - JAXB (Java API for XML Binding) : http://www.jcp.org/jsr/detail/31.jsp ; 

• JSR067 - JAXM (Java API for XML Messaging) : http://www.jcp.org/jsr/detail/67.jsp ; 

• JSR063 - JAXP (Java API for XML Processing) : http://www.jcp.org/jsr/detail/63.jsp ; 

• JSR093 -JAXR (Java API for XML Registries): http://www.jcp.org/jsr/detail/93.jsp; 

• JSR101 - JAX/RPC (Java API for XML based RPC) : http://www.jcp.org/jsr/detail/101.jsp. 

La premiere JSR (JSR109) constitue plutot ce que Ton peut appeler une specification de cadrage : 
elle a en effet pour objectif de definir le modele de developpement et F architecture d' execution 
necessaires a 1' implementation des services Web dans le contexte de la plate -forme J2EE. Le groupe 
de travail en charge de cette specification est pilote par Jim Knutson d'IBM. 

Cette specification est passee a l'etat de document de proposition finale (Proposed Final Draft), le 
31 aoiit 2002 (voir ftp://www6.software.ibm.com/software/developer/library/ws-jsr109-proposed.pdf), et a ete acceptee 
definitivement (Final Release), le 15 novembre 2002 (voir ftp://www-126.ibm.eom/pub/jsr109/spec/1.0/ 
websvcs-1_0-fr.pdf). 



Groupe d'experts 

La specification 109, finalement nommee Java Web Services for J2EE Specification, a ete produite par les 
membres actifs d'un groupe d'experts, issus des societes IBM, Sun Microsystems, Oracle, BEA, Sonic Software, 
SAP, Hewlett-Packard, SilverStream et IONA Technologies. Par ailleurs, d'autres experts, en provenance des 
societes EDS, Macromedia, Interwoven, Rational Software, Developmentor, interKeel, Borland, Cisco, ATG, 
WebGain, Sybase, Motorola et WebMethods, se sont associes a ce groupe de travail. 



La specification 109 traite des aspects suivants : 

le schema general de mise en ceuvre des services Web dans le cadre de la plate -forme J2EE ; 

le modele de programmation cote client ; 

le modele de programmation cote serveur ; 

les modules de traitement (handlers) ; 

les descripteurs de deploiement ; 

le deploiement ; 

la securite. 

Le document final de la specification 109 est accompagne d'une implementation de reference (voir 
ftp://www-126.ibm.eom/pub/jsr109/ri/1.0/wsee-1_0-lic.zip) et d'une boite a outils de compatibilite technologique 
TCK (Technology Compatibility Kit), destinee a verifier la compatibilite de 1' implementation d'une 
tierce partie (voir ftp://www-126.ibm.eom/pub/jsr109/tck/1.0/wseetck-1_0-lic.zip). 
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Les six specifications qui suivent la JSR 109 concernent des API de programmation destinees a etre 
implementees dans la plate-fomie Java selon les regies et le cadre de Farchitecture definie par la JSR 109. 

Outre ces premieres JSR, de nouvelles demandes ont ete proposees au JCR en relation avec les services 
Web, comme la gestion des pieces jointes SOAP, Futilisation de metadonnees Java proposee par BEA, etc. 

L'offre de SUN Microsystems : SUN ONE 

Officiellement, Scott McNealy, CEO de Sun, a annonce le developpement d'une nouvelle architec- 
ture orientee services, nominee Sun ONE (Open Net Environment), le 5 fevrier 2001 (voir annonce 
http://java.sun.com/features/2001/02/launch.html). L'objectif de cette nouvelle architecture est de simplifier 
la creation, 1' assemblage et le deploiement de « smart » Web services. Cette future offre de Sun est 
fondee sur les standards issus des technologies XML : LDAP, UDDI et Java. 

Depuis cette annonce initiale, Sun a publie d'autres communiques qui precisaient le contenu de cette 
nouvelle offre et les modalites d' apparition et de mise en ceuvre des logiciels inclus dans cette offre. 
De nombreuses annonces ont ete effectuees notamment lors des salons JavaOne 2001 et 2002 (inte- 
gration des nouveaux paquetages lies aux services Web dans le futur JDK 1 .4, sortie des JAX et des 
Java Web Services Developement packs, etc.). 

Le 15 avril 2002, Sun a plus precisement formalise l'offre Sun ONE en annoncant la fusion de ses 
differentes lignes de produits (rebranding), acquises lors de divers achats realises ces dernieres 
annees, sous la seule et unique denomination commerciale Sun ONE (voir http://www.sun.com/smi/Press/ 
sunflash/2002-04/sunflash.20020415.2.htmf). Les marques concernees, c'est-a-dire iPlanet, Forte, StarOf- 
fice et Chili !Soft, disparaissent done au profit de la nouvelle. 

Afin de mieux sensibiliser les developpeurs a cette nouvelle architecture technique et a l'offre 
commerciale qui en decoule, Sun a regroupe les principaux elements techniques de son offre, ainsi 
que la documentation disponible, sous la forme d'un produit, nomme Sun ONE Starter Kit (voir http:// 
wwws.sun.com/software/sunone/starterkit). Ce produit, disponible sous forme de supports CD ou DVD, 
contient la quasi-integralite des produits de la nouvelle ligne marketing de Sun et permet ainsi 
d'evaluer les differents logiciels sur des plates-formes Solaris, Windows ou Linux. 

Implementations de reference des JSR 

Le developpement de la nouvelle plate-forme se deroule sous le controle du JCP (Java Community 
Process : voir http://www.jcp.org), qui maitrise revolution de la plate-forme Java (voir la section prece- 
demment, « Les efforts de normalisation de la communaute Java »). Chacune des Java Specification 
Requests donne lieu au developpement d'une implementation correspondante. Les sites de ressources 
Sun associes a ces JSR sont les suivants : 

JSR03 1 - JAXB (Java API for XML Binding) : http://java.sun.com/xml/jaxb ; 

JSR067 - JAXM (Java API for XML Messaging) : http://java.sun.com/xml/jaxm ; 

JSR063 - JAXP (Java API for XML Processing) : http://java.sun.com/xml/jaxp ; 

JSR093 - JAXR (Java API for XML Registries) : http://java.sun.com/xml/jaxr ; 

JSRWl-JAX/RPC (Java API for XML based RPC) : http://java.sun.com/xml/jaxrpc. 
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A ce premier jeu de specifications prises en compte dans la plate-forme Sun ONE initiale est venue 
s'ajouter la specification SOAP with Attachments : SAAJ (SOAP with Attachments API for Java) : 
http://ja va.su n. com/xml/saaj. 



J AX Pack 



Pour faciliter l'acces des developpeurs a ces nouvelles implementations, celles-ci ont ete regrou- 
pees dans un paquetage : le JAX Pack. Ce paquetage est destine a etre reactualise tous les trimes- 
tres et a ete disponible en telechargement pour la premiere fois durant l'automne 2001. Cette 
version Java XML Pack Fall 01 FCS Bundle ne comportait que les API JAXM 1 .0 et JAXP 1 . 1 .3 et 
etait fonctionnelle sur les JDK 1.3.1 _0 1 et 1.4. 

La version suivante, « hiver 2001 », nommee Java XML Pack Winter 01 dev Bundle a introduit deux 
nouvelles API : JAXR 1.0 et JAX-RPC 1.0. Ces API, completees par de nouvelles versions des 
premieres API, JAXM 1 .0. 1 et JAXP 1 .2, sont toutes en versions Early Access. 

La troisieme mouture de ce paquetage, nommee Java XML Pack Spring 02 dev Bundle, consiste en 
une consolidation de la precedente version et n'introduit ni de nouvelles API, ni de nouvelles 
versions des API existantes. Celles-ci passent simplement du stade Early Access 1 a Early Access 2. 
Nous sommes done toujours en presence d'une version de developpement de ce paquetage. 

La quatrieme version devait introduire la demiere API JAXB. Malheureusement, cette API n'est pas 
au rendez-vous. La version Java XML Pack Summer 02 Bundle ne comporte toujours que les API 
precedentes, mais en version definitive : JAXM 1.1, JAXP 1.2, JAXR 1.0_01 et JAX-RPC 1.0. Cette 
version voit egalement apparaitre la prise en charge de la specification SOAP with Attachments via 
une nouvelle API SOAP with Attachments API for Java (SAAJ) 1.1. Cette quatrieme version a ete 
validee avec le serveur Tomcat 4.0.1 et 4.0.3, J2EE 1.3_01 et 1.3.1, J2SE 1.3.1_03, 1.4 et 1.4.01. 
L introduction de la derniere API JAXB est ainsi reportee a une version ulterieure du JAX Pack. 

Une cinquieme version a ete publiee durant l'automne 2002. Cependant, celle-ci n'est en realite 
qu'une mise a jour de la quatrieme version, d'oil sa denomination : Java XML Pack Summer 02 
update Bundle. Cette cinquieme version a ete validee avec le serveur Tomcat 4.0.3, J2EE 1.3.1, 
J2SE 1.3.1_03, 1.4. LAPI JAXB n'est toujours pas presente dans cette version du JAX Pack. 

Le JAX Pack peut etre telecharge a l'adresse http://java.sun.com/xml/downloads/javaxmlpack.html. 
Tableau 14-1. Tableau resume des versions de Java XML Packs 
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Java Web Services Development Pack (WSDP) 

Un second paquetage, plus etendu que le JAX Pack, est telechargeable a partir du site de Sun Micro- 
systems. Le Java Web Services Development Pack (WSDP) est un ensemble logiciel qui apporte aux 
developpeurs l'ensemble des API presentes dans le JAX Pack, ainsi que les elements d'une plate- 
forme d' execution complete. 

La premiere version de ce pack Early Access Release 1 comportait les implementations des quatre API 
du paquetage JAX Pack au niveau « printemps 2002 », completees d'une librairie de balises JSP, d'une 
implementation d'un annuaire prive UDDI de test, d'un container d' execution Apache Tomcat, d'une 
implementation JSSE (Java Secure Socket Extension) et du gestionnaire d' assemblage Apache Ant. 

Une seconde version de ce pack (version 1.0), sortie en juin 2002, reunit les cinq API du JAX Pack au 
niveau de la quatrieme version (Java XML Pack Summer 02 Bundle), toujours accompagnees de la 
librairie de balises JSTL 1.0 (JSP Standard Tag Library), de 1' implementation d'un annuaire prive 
UDDI de test Registry Server 1.0_01, du container d' execution Apache Tomcat 4.1.2 et d'un outil de 
deploiement d' applications Web (Web Application Deployment Tool). 

Une troisieme version de ce pack (version 1.0_01), sortie a l'automne 2002, reunit toujours les cinq 
API du JAX Pack au niveau de la cinquieme version (Java XML Pack Summer 02 update Bundle), 
toujours accompagnees de la librairie de balises JSTL 1.0.1, de 1' implementation de l'annuaire prive 
UDDI de test Registry Server 1.0_02, du container d'execution Apache Tomcat 4.1.2 et de l'outil de 
deploiement d' applications Web, Web Application Deployment Tool. 

Le Java Web Services Development Pack peut etre telecharge a l'adresse http://java.sun.com/webservices/ 
downloads/webservicespack.html. 

Dans la pratique, comme nous l'avons vu auparavant, c'est la vitesse d'evolution de ce dernier pack 
qui conditionne la sortie de J2EE 1 .4. 

Java Web Services Tutorial 

Ann d' aider les developpeurs a utiliser les nouvelles API de la plate-forme Java, et plus particuliere- 
ment le Java Web Services Development Pack, Sun a developpe un guide dedie a cet usage : le Java 
Web Services Tutorial. 

Celui-ci presente les API suivantes : 

Java API for XML Messaging (JAXM) ; 

Java API for XML Processing (JAXP) ; 

Java API for XML Registries (JAXR) ; 

Java API for XML based RPC (JAX/RPC) ; 

Java Servlets ; 

JavaServer Pages ; 

JavaServer Pages Standard Tag Library (JSTL) ; 

gestionnaire d' assemblage Apache Ant ; 

serveur de JSP/Servlets Apache Tomcat. 
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Le guide de developpement Java Web Services Tutorial peut etre telecharge a l'adresse http:// 
java.sun.com/webservices/downloads/webservicestutorial.html. 

L'offre de BEA systems 

BEA Systems a reagi tardivement par rapport a Favancee d'IBM dans le domaine des services Web. 
BEA n'a pas participe aux differents processus initiaux de specification. 

La premiere annonce de BEA (voir http://www.bea.com/press/releases/2001/0226_web_services.shtmi), datee 
du 26 fevrier 2001, presentait la strategie et la plate-forme destinee a prendre en charge les services 
Web et plus particulierement les specifications SOAP, WSDL, UDDI, BTP et ebXML. Cette plate- 
forme initiale s'appuyait sur les produits WebLogic Server, WebLogic Collaborate et WebLogic 
Process Integrator. 

La mise en disponibilite de la version 7.0 du serveur WebLogic de BEA, le 30 avril 2002, a ete 
l'occasion d'une reformulation de l'offre de BEA autour de WebLogic Platform 7.0, disponible 
depuis fin juin 2002. Cette nouvelle offre regroupe les produits WebLogic Portal 7.0 (environnement 
de portail), WebLogic Integration 7.0 (services d' integration) et WebLogic Workshop (environnement 
de developpement). 

WebLogic 6.1 et 7.0 

La version 6.1 de WebLogic Server est la premiere a prendre en charge les services Web dans la 
gamme de BEA Systems : celle-ci est disponible depuis aout 2001 (voir annonce http://www.bea.com/ 
products/weblogic/server/announcing.shtml) en version certifiee J2EE 1.2 et en version non certifiee 
J2EE 1.3. Des versions devaluation peuvent encore etre telechargees a http://commerce.beasys.com/ 
downloads/weblogic_server.jsp#wis. 

La version 6.1 de WebLogic a ete remplacee par la version 7.0 (voir annonce http://www.bea.com/press/ 
releases/2002/0430_wls7_now_available.shtml), disponible depuis le 30 avril 2002. Cette derniere version 
est certifiee J2EE 1.3. Elle integre done une implementation JAXP 1.1. Lanalyseur syntaxique XML 
utilise est nouveau, ce n'est plus celui de la communaute Apache (Xerces) utilise dans la version 6.1. 
En outre, cette nouvelle version est en avance par rapport a J2EE 1 .4 et incorpore deja une implemen- 
tation de la specification JAX-RPC de la communaute JCP Une version d' evaluation, valable quatre- 
vingt-dix jours, peut egalement etre telechargee a http://commerce.beasys.com/downloads/weblogic_server 
.jspffwls. 

Lors de la manifestation BEA eWorld Europe 2002, qui s'est tenue les 25 et 26 juin 2002 a Paris (voir 
http://eu.bea.com/events/eworld2002/index.htm), BEA a introduit son offre WebLogic Platform 7.0, qui 
regroupe, outre le serveur d' applications WebLogic 7.0, les produits WebLogic Portal 7.0 (environ- 
nement de portail), WebLogic Integration 7.0 (services d' integration) et WebLogic Workshop (envi- 
ronnement de developpement de services Web : voir la section suivante). Cette nouvelle offre de 
BEA est disponible depuis la fin du mois de juin 2002 (voir annonce http://www.bea.com/press/releases/ 
2002/0625_platform_ship.shtmi). Une version devaluation peut etre telechargee a http://www.bea.com/ 
products/weblogic/platform/index.shtml. 
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WebLogic Workshop 

En matiere d'environnement de developpement, BEA offre un nouveau produit : BEA WebLogic 
Workshop (voir http://www.bea.com/products/weblogic/workshop/index.shtml), specialement dedie aux appli- 
cations de type services Web. Ce nouvel environnement prend en charge les specifications SOAP 1.1, 
WSDL 1.1, et UDDI 2.0. En ce qui concerne les protocoles de transport, HTTP et JMS sont pris en 
charge. L' environnement d' execution (runtime) de Workshop se presente comme une application 
J2EE. Par ailleurs, cet environnement s'appuie sur Futilisation de fichiers JWS (Java Web Service) 
qui permettent d'enregistrer des metadonnees relatives au code source Java. Cette gestion de meta- 
donnees est formalisee a travers les travaux de deux groupes de travail qui officient dans le cadre de 
la communaute JCP : la JSR 175 (A Metadata Facility for the Java Programming Language : voir 
http://www.jcp.org/jsr/detail/175.jsp) et la JSR 181 (Web Services Metadata for the Java Platform : voir 
http://www.jcp. org/jsr/detail/1 81.jsp) . 

WebLogic Workshop permet a BEA de combler une lacune en ce qui concerne F environnement de 
developpement Java associe a son serveur d' applications, a Finstar dTBM qui proposait VisualAge 
for Java, remplace depuis par WebSphere Studio Application Developer, en complement de son 
serveur d' applications WebSphere. 

Jusque recemment, BEA proposait le produit WebGain Studio de la societe WebGain (http:// 
www.webgain.com), un spin-off de BEA, cree en 2000 avec Faide de Warburg Pincus Ventures. Ce 
produit a ete progressivement cree via F acquisition et/ou F integration de produits existants ou de 
licences logicielles : rachat du produit VisualCafe (environnement de developpement) a Symantec en 
Janvier 2000, achat de Tendril Software et de son produit Structure Builder (modelisation, conception 
et developpement d'EJB), rachat du produit TopLink (mapping relationnel/objets) a la societe The 
Object People en avril 2000. . . 

La derniere version de WebGain Studio (7.0), adaptee au developpement de services Web Java (qui 
prend en charge les specifications SOAP, WSDL et UDDI), etait prevue pour une disponibilite simul- 
tanee avec la sortie du serveur d' applications WebLogic 7.0 (voir annonce http://www.prnewswire.com/ 
cgi-bin/micro_stories.pl?ACCT=150980&TICK=WBGN&STORY=/www/story/03-28-2002/ 
0001695662&EDATE=Mar+28,+2002). 

II semble cependant que BEA ait decide d'abandonner WebGain Studio au profit du nouvel environ- 
nement Workshop developpe en interne. De fait, comme le precise la page d'accueil du site Web de 
la societe, WebGain a progressivement stoppe son activite (winding down) et revendu ses actifs de 
propriete intellectuelle. La gamme TopLink a ete cedee a Oracle (voir http://www.oracle.com), le produit 
Application Composer a DigiSlice (voir http://www.digislice.com) et WebGain Studio a TogetherSoft 
(voir http://www.togethersoft.com). Cette derniere societe a ete absorbee depuis par Borland. WebGain 
peut cependant fournir certains de ses produits encore en stock. 

Le produit WebLogic Workshop est issu d'un projet dont le nom de code etait Cajun. Ce projet est 
lui-meme issu d'une technologie developpee par une societe creee en fevrier 2000 par d'anciens 
employes de Microsoft, dont Adam Bosworth, Rod Chavez et Tod Nielsen : Crossgain (http://www.cros- 
sgain.com). Cette societe a ete rachetee en juillet 2001 par BEA et se trouve done directement a 
Forigine de ce nouvel environnement de developpement. Celui-ci est maintenant integre dans le 
produit WebLogic Platform 7.0, et une version devaluation peut etre obtenue a http://commerce.bea 
.com/downloads/weblogicjplatform.jsp. 
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Ressources developpeur 

Un site de ressources est accessible a http://developer.bea.com/techtrack/detail.jsp?highlight=webservices : le 
Web Services Technology Track. Pour integrer SOAP a WebLogic 5.1 et 6.0, BEA proposait prece- 
demment en telechargement un paquetage en version beta, reposant sur le parser Xerces et F imple- 
mentation SOAP d' Apache, mais la societe les a retire de son site pour les remplacer par un lien 
direct vers le site Apache (voir using SOAP with WebLogic 5. 1 and/or 6.0). 

L'offre de Hewlett-Packard : Netaction 

Hewlett-Packard est Tun des acteurs de la premiere heure dans le monde des services Web. En effet, 
c'est des 1999 que Hewlett-Packard publiait une architecture orientee services nominee e-Speak 
C'est en realite la premiere architecture a avoir defini le concept de service Web dans son acception 
actuelle. Toutes les notions evoquees aujourd'hui dans le domaine des services Web etaient deja 
presentes dans ce produit. 

Malheureusement, cette nouvelle technologie est arrivee trop tot par rapport a la demande du marc he. 
De surcroit, cette plate-forme s'appuyait sur certains composants proprietaries : par exemple, les 
echanges etaient pris en charge par la librairie J-ESI (Java e-Speak Service Interface), via un protocole 
de messagerie et de transport proprietaire. 

Netaction : renaissance de e-Speak 

L' arrivee des specifications SOAP, WSDL et UDDI a oblige Hewlett-Packard a reevaluer son offre 
e-Speak et a la retravailler pour l'adapter aux nouveaux standards de l'offre. Cet aggiornamento s'est 
traduit par l'apparition du programme HP Netaction. Ce programme s'appuie sur les produits 
suivants : 

• HP Application Server, le serveur d' applications Java de Hewlett-Packard, heritier de l'un des 
premiers serveurs d' applications Bluestone Sapphire/Web, puis HP Bluestone Total-e-Server 
(voir http://www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/hp-as/default.jsp) ; 

• HP Process Manager, un gestionnaire de processus en technologie J2EE (voir http:// 
www. ice. hp. com/cyc/af/00/index.html) ; 

• HP Web Services Platform, en realite le successeur de la technologie e-Speak (voir http:// 
www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/hp_web_services/default.jsp) ; 

• HP Total-e-Mobile, une plate -forme de prise en charge des applications mobiles (voir http:// 
www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/Total-e-Mobile/default.jsp) ; 

• HP Total-e-Syndication, une plate-forme de syndication de contenus (voir http://www.blues- 
tone. com/SalSAPI. dll/SaServletEngine. class/products/Total-e-Syndication/default.jsp) ; 

• HP Total-e-Transactions, une plate-forme de gestion transactionnelle (voir http://www.blues- 
tone.com/SalSAPI.dll/SaServletEngine.class/products/Total-e-Transactions/default.jsp). 

Tous ces produits peuvent etre telecharges pour etre evalues a l'adresse http://www.bluestone.com/ 
Salsapi.dll/SaServletEngine.class/products/forms/downloads.jsp. Hewlett-Packard a done stoppe le develop- 
pement de la plate-forme e-Speak, et a concentre ses ressources sur cette nouvelle offre. Les princi- 
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pales differences entre les plates-formes e-Speak et Web Services de Hewlett-Packard sont expli- 
citees dans le document hp web services platform: a comparison with hp e-speak (voir http:// 
www. hpmiddleware. com/downloads/pdf/espeak_ webservices.pdf) . 

HP Web Services 2.0 

Parmi les differents composants de cette offre Netaction, c'est done la plate-forme HP Web Services 
qui prend en charge le support des technologies de services Web. Cette plate-forme, actuellement en 
version 2.0 comprend les elements suivants : 

• HP-SOAP 2.0 : le moteur d'execution SOAP qui integre egalement un framework de traite- 
ment en mode pipeline de documents XML. Celui-ci s'appuie sur le produit Cocoon2 
d' Apache (voir http://xml.apache.org/cocoon/index.html) ; 

• HP Service Composer : l'outil de developpement et de deploiement d'un service Web sur le 
serveur HP AS 8.0 ; 

• HP Registry Composer : cet outil est utilise pour acceder a des annuaires UDDI. II permet 
d'enregistrer et de rechercher des services Web sur n'importe quel annuaire UDDI. 

La plate-forme HP Web Services necessite un JDK 1.3 au minimum pour fonctionner. Elle prend en 
charge les systemes d' exploitation suivants : 

• HP-UX 11.11 ; 

• Windows 2000; 

• Windows NT 4.0 SP6 ; 

• Sun Solaris 8 ; 

• Red Hat Linux 7.1. 

Les serveurs qui s'appuient sur Apache, ainsi que les plug-ins IS API et NSAPI, sont pris en charge. 
Parmi ceux-ci, on peut retenir : 

• Apache 1.3.19 ; 

• Microsoft IIS 4.0 et 5.0 ; 

• IPlanet. 

Differents serveurs d' applications Java sont egalement pris en compte, dont : 

• HP-AS8.0; 

• Apache Tomcat ; 

• BEAWebLogic5.1et6.1. 

Les specifications prises en charge par la plate-forme de Hewlett-Packard sont SOAP, WSDL, UDDI, 
JAXM et XML Digital Signatures. 

Les implementations externes utilisees sont les analyseurs syntaxiques XML Xerces et XSL Xalan de 
la communaute Apache. Hewlett-Packard fait egalement appel au framework de publication Cocoon2 
de la communaute Apache. Enfin, il utilise aussi le paquetage client UDDI4J d'origine IBM pour son 
produit Registry Composer. 
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Bien entendu, cette plate-forme est parfaitement integree au serveur d' applications Java HP- AS de 
Hewlett-Packard. Elle est implementee sous forme de servlets Java. Elle est egalement capable de 
fonctionner sous d'autres serveurs d' applications : la documentation disponible montre notamment 
comment l'installer sous les serveurs Apache Tomcat 3.3 et 4.0.3 ou sous les serveurs BEA 
WebLogic5.1 et 6.1. 

HP Web Services Registry 2.0 

Par ailleurs, Hewlett-Packard a annonce le 26 octobre 2000 sa participation au projet UDDI (voir 
annonce de presse : http://www.hp.com/hpinfo/newsroom/press/26oct00b.htm). Puis, F annonce du demarrage 
en production du annuaire metier UDDI 1.0 (UDDI Business Registry) par la communaute UDDI 
(voir http://www.uddi.org/uddipr05022001.html) a informe par la meme occasion que Hewlett-Packard 
deviendrait operateur de 1' annuaire pour la prochaine version 2.0. 

Cette participation importante dans l'organisation UDDI s'est traduite par l'arrivee d'une nouvelle 
implementation d' annuaire UDDI prive : le produit HP Web Services Registry 2.0 (voir - http:// 
www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/hp_web_services/registry/default.jsp). Cet annuaire 
a ete d'emblee disponible en version UDDI 2.0 et peut interoperer avec d'autres annuaires UDDI, 
prives ou publics. 

HP Web Services Transactions 1.0 (HP WST) 

Enfin, le 13 mai 2002, Hewlett-Packard a devoile la premiere implementation commerciale de la 
specification du protocole de transactions metier BTP (Business Transaction Protocol) du consortium 
OASIS. Ce produit se nomme HP Web Services Transactions 1.0 (HP WST) ; voir http:/ /www. hpmid- 
dleware.com/downloads/pdf/wst_specsheet.pdf. II s'integre bien sur avec les elements de la plate-forme 
HT Web Services, comme le serveur HP-SOAP et le HP Registry Composer, ainsi que le serveur 
d' applications HP-AS. Cette implementation de BTP restera vraisemblablement Fune des seules, car 
la publication des specifications BPEL4WS, WS-Transaction et WS -Coordination, qui a eu lieu en 
aoiit 2002, risque d'etre fatale a revolution de la specification BTP. 

HP Middleware : arret partiel de I'activite 

Malheureusement, ces produits ont disparu du catalogue de Hewlett-Packard. En effet, suite a la 
fusion de Hewlett-Packard et Compaq, le groupe a redefini sa strategie dans le domaine du logiciel, 
et plus particulierement des services Web, en juillet 2002 (voir annonce du 15 juillet : http://www.biues- 
tone.com/downloads/pdf/HPAS_SunsetCustomerLetter-JUL152002_FINAL.pdf). 

Les principales considerations a l'origine de cette decision sont notamment : 

• la consolidation dans le domaine du middleware J2EE (voir parts de marche de BEA et 
d'IBM) ; 

• l'emergence de la plate-forme .NET. 

Pour compenser cet arret partiel de I'activite de la division HP Middleware, Hewlett-Packard a 
decide de s'appuyer sur des partenariats strategiques, avec des societes importantes dans leurs domai- 
nes d'activite telles que BEA, Microsoft, Tibco, webMethods, etc. autour des deux plates-formes de 
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reference J2EE et .NET. Par ailleurs, un programme de migration et d'assistance des clients actuels 
des produits arretes vers les produits equivalents de BEA, et notamment le serveur d' applications 
WebLogic, a ete etabli et publie des le 30 juillet 2002 (voir annonce http://www.bluestone.com/downloads/ 
pdf/HPAS_SunsetCustomerLetter-JUL302002_FINAL.pdf). 

Les produits concernes par cet arret partiel sont : 

HP Application Server ; 

HP Application Server Resilient Edition ; 

HP Web Services Platform ; 

HP Web Services Registry ; 

HP Web Services Transactions ; 

HP Core Services Framework ; 

HP Total -e-Server. 

Comme on peut le voir, la quasi-integralite des produits dedies a la mise en ceuvre des services Web sont 
concernes par cette decision. Ceci met done fin aux efforts importants du pionnier Hewlett-Packard 
dans le domaine des services Web, effectues au travers des programmes e-Speak et NetAction. 

Les informations relatives a ce programme de desengagement (programme Sunset) sont accessibles a 
http://www.bluestone.com/SalSAPI.dll/SaServletEngine.class/sunset/default.jsp. 

Cependant, Hewlett-Packard n'en abandonne pas pour autant les technologies liees aux services Web. 
En effet, conscientes du potentiel important de ces nouvelles technologies et de l'impact qu'elles 
auront dans le domaine du middleware et des infrastructures, les societes Hewlett-Packard et 
webMethods ont propose une nouvelle specification, FOMI (Open Management Interface), une 
initiative destinee a favoriser la gestion de systemes qui s'appuient sur l'utilisation de services Web 
(voir http://www.oasis-open.org/committees/mgmtprotocol/Docs/OMISpecification_1.Orev1_OASIS.pdfetannoncea 
http://www.openview.hp.com/library/press/2002/april/Press_HTML-137.asp). 

Ainsi, par exemple, une console Hewlett-Packard OpenView sera en mesure de superviser une plate- 
forme d'integration webMethods et de remonter des alertes en cas de probleme d' exploitation, ou de 
collecter des informations de mesure dans le cadre de la surveillance de contrats de service SLA 
(Service Level Agreements). 

L off re de IONA Technologies 

IONA Technologies (voir http://www.iona.com), fondee en 1991 et basee a Dublin, apres avoir ete l'un 
des acteurs majeurs dans l'edition de produits dedies aux architectures CORBA, s'oriente vers les 
technologies de services Web. Cette orientation a cependant ete plus tardive que celle adoptee par 
certains de ses employes qui sont a l'origine de nouvelles societes specialisees dans ce domaine dont 
Cape Clear et Shinka Technologies. 

En fevrier 2002, IONA a annonce son nouveau produit : Orbix E2A Web Services Integration Platform. 
Ce produit s'ajoute au serveur d' applications de IONA Orbix E2A Application Server Platform. 

Le produit Web Services Integration implemente de nombreuses specifications telles que ebXML, 
RosettaNet, ainsi que EDI, cXML et xCBL. II peut offrir une interface, via des connecteurs, avec de 
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nombreuses technologies et de nombreux produits tels que Corba, J2EE, JMS, MQSeries, SAP, 
Siebel et PeopleSoft. 

La plate-forme Web Services Integration est declinee en deux editions : 

• l'edition XMLBus, une infrastructure complete de gestion de services Web dediee au deve- 
loppement, au deploiement, a l'integration et a l'exploitation de ces technologies (voir http:// 
www.iona.com/products/webserv-xmlbus.htm) ; 

• l'edition Collaborate Enterprise Integrator, une plate-forme de gestion collaborative qui se 
positionne de la meme facon que WebLogic Collaborate ou WebSphere Business Integrator. 
Cette edition s'appuie sur les fonctionnalites de l'edition XMLBus (voir http://www.iona.com/ 
products/webserv-collaborate.htm). 

L'edition XMLBus prend en charge les specifications SOAP, WSDL et UDDI. Elle prend egalement 
en charge les API SOAP with Attachments, JAXR, JAXM, SAML et WSIL. 

La derniere version disponible est la version 5.4. Un site developpeur dedie est accessible a http:// 
www.xmlbus.com. II contient egalement une section liee a la question de l'interoperabilite : le Web 
Services Interoperability Forum (voir http://www.xmlbus.com/interop). 

L off re de Novell 

Novell (voir http://www.novell.com), toujours a la recherche d'une nouvelle offre de substitution a son 
celebre systeme d' exploitation de reseaux NetWare, apres un premier virage vers les technologies 
Internet a la fin des annees 1990, semble maintenant vouloir jouer un role important dans le domaine 
des services Web. 

En effet, le 10 juin 2002, Novell a annonce son intention d'acquerir, pour deux cent douze millions 
de dollars, la societe SilverStream (voir http://www.silverstream.com), dont le serveur eponyme est histo- 
riquement Fun des premiers serveurs d' applications Java, aux cotes de Bluestone (rachete depuis par 
Hewlett-Packard) et de Tengah, devenu depuis WebLogic (voir texte de 1' annonce : http:// 
www. novell. com/news/press/archive/2002/06/pr02045. htmi) . 

Cette acquisition de SilverStream par Novell a ete finalisee le 22 juillet 2002 (voir http://www.silverstream 
. com/Website/app/en_ US/PressReleaseDetail?id=6ea68db8369943dab4e4f3c084d0cb 1 d) . 

La societe SilverStream, victime de la course aux parts de marche des serveurs J2EE, declenchee 
entre WebSphere et WebLogic au debut des annees 2000, s'est tres vite orientee vers une offre de 
produits plus verticaux, capables de fonctionner sur son propre serveur d' applications, mais egale- 
ment sur des serveurs d' applications concurrents. Tres rapidement, cette offre s'est interessee aux 
technologies liees aux services Web. 

C'est ainsi que le serveur SilverStream, dote d'une implementation SOAP, etait present lors de la 
premiere confrontation d'interoperabilite, nominee SOAP Builders Round I , qui s'est tenue dans les 
locaux d'IBM a Raleigh Durham, debut 2001 (voir chapitre 17 : « Le defi de l'interoperabilite »). Les 
resultats de ces premiers tests furent presentes lors du salon NetWorld+Interop de Las Vegas (du 8 au 
10mai2001). 

Cette nouvelle offre de SilverStream, regroupee sous le nom generique d'eXtend, recouvre en prati- 
que un environnement complet de developpement, de deploiement et de gestion d' applications Web 
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qui s'appuient sur les standards et specifications J2EE et services Web. Cette offre s'appuie sur les 
compos ants suivants : 

• l'environnement de developpement integre (Workbench) ; 

• le portail d' applications interactives (Director) ; 

• le serve ur d' integration (Composer) ; 

• le serveur d' applications J2EE (Application Server) ; 

• l'environnement d'execution de services Web (jBroker). 

Cette offre est completee par un site de ressources, dont une partie, DevCenter, est orientee vers les 
developpeurs (voir http://devcenter.silverstream.com/DevCenter/DevCenterPortal?PID=DevCenter.html). 

Suite a l'acquisition de SilverStream par Novell, l'offre SilverStream eXtend s'est transmutee en 
Novell exteNd, dont une version 4.0 a ete annoncee le 7 octobre 2002 (voir annonce http://www.silvers- 
tream.com/Website/app/en_US/PressReleaseDetail?id=9e706f1c86cd4f9dbd543106c10b3b29). Cette derniere 
version est compatible J2EE 1.3. 

Composer : le serveur a" integration 

Le serveur d'integration exteNd Composer est une application J2EE destinee a faciliter F integration 
des systemes patrimoniaux des entreprises (legacy systems) et a les integrer dans un systeme d'auto- 
matisation de processus. 

II est ainsi possible de construire et de reutiliser ensuite Faeces a des fonctionnalites existantes sur 
des systemes de type grands systemes (mainframes : applications de type 3270, 5250, Telnet ou 
CICS), des modules SAP, des systemes trans actionnels EDI ou des bases de donnees. 

Le moteur d'execution du serveur s'appuie sur la specification Web Services Flow Langage (WSFL) 
d'IBM et offre un environnement visuel de cartographie de donnees (mapping) et de transformation 
a base d'interface de type drag and drop. 

Le deploiement des services et composants developpes pour ce serveur peut etre effectue sur les 
serveurs d' applications J2EE cibles Novell (ex-SilverStream), WebSphere et WebLogic. 

De meme, le serveur d'integration exteNd Composer dispose de son propre environnement integre 
UDDI et est apte a publier les services Web ainsi developpes sur un annuaire public ou prive, ou bien 
a decouvrir des services externes. 

Les caracteristiques du produit Novell Composer peuvent etre consultees a Fadresse http://www.silverstream 
. com/Website/app/en_ US/Composer. 

Workbench : l'environnement de developpement integre 

L'environnement de developpement integre Workbench est un environnement complet de developpe- 
ment J2EE et services Web. 

Celui-ci permet de manipuler des objets aussi divers que des services Web, des classes Java, des EJB, 
des servlets, des documents XML, des pages JSP, des descripteurs de deploiement J2EE, des librairies 
de balises JSP ou encore des JavaBeans. 
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L'environnement dispose notamment d'editeurs XML et XSL. 

L'environnement de developpement s'appuie sur le moteur d'execution de services Web j Broker 
(voir ci-apres) de Novell (ex-SilverStream). 

Les caracteristiques du produit Novell Workbench sont decrites a Fadresse http://www.silverstream.com/ 
Website/app/en_ US/Workbench. 

JBroker : l'environnement d'execution 

L'environnement d'execution jBroker autorise le deploiement et F execution de services Web. II fonc- 
tionne de maniere integree avec l'environnement Workbench. 

Celui-ci represente une implementation de la specification JCP JAX-RPC 1.0 et est interoperable 
avec les implementations SOAP les plus repandues dont Apache SOAP et Microsoft .NET. 

Cet environnement est capable de generer des servlets qui peuvent ensuite etre deployes dans tout 
moteur d'execution Servlets/JSP. II est bien entendu integre dans le serveur d' applications Novell 
(ex-SilverStream). 

II faut remarquer que cet environnement d'execution SOAP prend en charge egalement le protocole 
de transport JMS et les pieces attachees SOAP (SOAP with attachments). II implemente aussi les 
fonctionnalites d'un courtier d'objets (ORB). 

Les caracteristiques du produit Novell jBroker sont accessibles a l'adresse http://www.silverstream.com/ 
Website/app/en_ US/J Broker. 

L'offre d'Oracle 

Oracle (voir http://www.oracle.com) est un des acteurs importants du monde Java, demeure relativement 
discret depuis l'eclosion des technologies liees aux services Web. 

Une premiere annonce marketing, nommee « Dynamic Services Framework », avait ete presentee fin 
2001, mais elle n' avait pas reellement ete suivie de realisations concretes. II a fallu en realite attendre 
l'arrivee des produits de la gamme integree Oracle9/, durant l'annee 2002, pour commencer a dispo- 
ser de logiciels qui implementent les specifications SOAP, WSDL et UDDI. Meme la presentation 
des caracteristiques de la version initiale de Oracle9; (mai 2001) ne faisait qu'effleurer la notion de 
service Web : http://otn.oracle.com/products/oracle9i/pdf/9i_new_features.pdf. 

Ce decalage peut vraisemblablement s'interpreter comme une consequence de la mise a jour a 
laquelle Oracle a du proceder afin de prendre en charge des applications Java dans son offre. En effet, 
l'ancienne implementation Java d'Oracle a ete remplacee, durant l'annee 2001 (voir annonce : http:// 
www.oracle.com/corporate/press/index.html7759347.html), par une version adaptee du serveur d' applications 
Orion (voir http://www.orionserver.com) d'lronFlare, l'une des implementations J2EE les plus perfor- 
mantes du moment. 

II semble cependant que cette discretion initiale soit oubliee avec 1' apparition d'une section « Tech- 
nology Center » dediee a ces nouvelles technologies sur le site d'Oracle Technology Network (voir 

http://otn. oracle, com/tech/webservices/content.html) . 
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Cette section du site Oracle regroupe toutes les informations necessaires aux developpeurs et aux 
architectes qui s'interessent a la maniere dont ces technologies ont ete integrees dans les produits 
Oracle : 

• plate -forme de deploiement et d'execution Oracle9zAS Containers for J2EE 9.03 ; 

• environnement de developpement Oracle9i JDeveloper ; 

• annuaire UDDI Oracle9/AS UDDI Registry 9.03 ; 

• publication de scripts PL/SQL sous forme de services Web, etc. 

Les autres technologies Java 

D'autres alternatives aux grands editeurs du monde Java et aux communautes Open Source bien 
etablies sont apparues tres tot sur le marche et ont su faire preuve d'un dynamisme et d'une inventi- 
vite remarquable. Nombre de ces alternatives sont representees par de nouvelles societes ou par des 
start-ups. Parmi ces societes, on peut citer notamment : 

• Cape Clear (http://www.capeclear.com), creee en septembre 1999 par d'anciens dirigeants de 
IONA Technologies, elle propose 1' environnement d'execution CapeConnect et l'environne- 
ment de conception, de developpement et de deploiement CapeStudio ; 

• The Mind Electric (http://www.themindelectric.com), fondee en fevrier 2001 par Graham Glass, elle 
offre deux produits de natures differentes, mais complementaires : 1' environnement de deve- 
loppement et de deploiement de services Web Glue et la plate -forme d'execution de type 
grille d' ordinate urs (grid computing) orientee services Gaia ; 

• Shinka Technologies (http://www.shinkatech.com), fondee en 1999 egalement par des anciens de 
IONA Technologies, elle presente la plate -forme d'integration Shinka Business Integration 
Platform ; 

• Systinet (http://www.systinet.com), ex-Idoox, fondee en Pan 2000 par l'ancien fondateur de 
NetBeans, Roman Stanek, elle propose de nombreux produits en technologie Java ou C++ 
parmi lesquels on peut citer : WASP Server (for Java et for C++), WASP UDDI (Standard et 
Enterprise Edition), WASP Developer (disponible sous forme de plug-ins pour Sun Forte for 
Java/NetBeans, Borland JBuilder et Eclipse), WASP Secure Identity ; 

• Bowstreet (http://www.bowstreet.com) a ete creee en 1999 et offre l'une des toutes premieres 
plates-formes dediees a la prise en charge de services Web : le produit Business Web Factory. 
Bowstreet s'est egalement interessee aux portails Web et propose depuis peu un nouveau 
produit, Portlet Factory for IBM WebSphere ; 

• Collaxa (http://www.collaxa.com), fondee fin 2000, par d'anciens responsables des societes Netscape, 
AOL, NetDynamics, NeXT et Electron Economy, s'est specialised dans le domaine de 
l'orchestration de services Web et propose l'une des premieres implementations commer- 
ciales de la specification BPEL4WS, sous la forme de son Web Service Orchestration Server ; 

• PolarLake (voir http://www.polarlake.com), creee en 2001 a partir d'un projet initie en 1999 par la 
societe XIAM (voir http://www.xiam.com), propose des produits centres sur le monde XML qui 
incorporent la technologie Dynamic XML Runtime, ainsi que le framework d' assemblage 
d' applications XML Circuits. Deux produits notamment sont dedies a la prise en charge des 
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services Web : la plate-forme de deploiement PolarLake et l'environnement de developpement 
rapide PolarLake Web Services Express ; 

• Alto Web (voir http://www.altoweb.com), fondee par Ali Kutay, le premier PDG de BEA, elle offre 
une plate-forme de developpement et de deploiement de services Web appelee AltoWeb 
Application Platform ; 

• Sonic Software (voir http://www.sonicsoftware.com), filiale de Progress Software, creee en Janvier 
2001, specialiste des systemes de messagerie Java (JMS), elle offre une plate-forme de deploie- 
ment de services Web Sonic XQ, qualifie de « premier bus de services d'entreprise » (ESB ou 
Enterprise Service Bus), capable de fonctionner sur son serveur de messagerie Sonic MQ. 

The Mind Electric Glue et Gaia 

The Mind Electric (voir http://www.themindelectric.com), entreprise texane (etablie a Dallas) fondee en 
fevrier 2001 par Graham Glass (voir http://www.themindelectric.com/company/index.html), concoit, elabore 
et distribue des plates-formes d' infrastructure pour applications reparties. 

Glue 

Son premier produit, Glue (voir http://www.themindelectric.com/glue/index.html), 100 % Java, permet de 
construire, de deployer et d'invoquer des services reseaux locaux et distants. Glue s'appuie sur les 
standards Internet HTTP, SSL, XML, WML, SOAP, WSDL et UDDI et interopere avec les plates- 
formes Microsoft .NET, IBM Web Services ToolKit, Apache SOAP ainsi que d'autres plates-formes 
de services Web compatibles avec SOAP 1.1. 

Glue offre les fonctionnalites suivantes : un microserveur Web HTTP et HTTPS, un moteur de 
servlets compatible Java Servlet 2.2, un generateur WSDL dynamique, un processeur SOAP 1.1, un 
serveur de persistance XML, un client et un serveur UDDI, un generateur de proxy-services Java, des 
boites a outils HTML et WML, et enfin un langage de script Electric Server Pages, alternatif aux 
JavaServer Pages. La prise en charge des JavaServer Pages a ete introduite dans les dernieres versions 
du produit. En outre, Glue incorpore un nouvel analyseur syntaxique XML DOM Electric XML tres 
rapide et simple a utiliser (voir http://www.themindelectric.com/exml/index.html). 

Electric XML 

La plate-forme Glue a ete l'objet de soins importants en matiere de performance : selon Fediteur, 
l'analyseur syntaxique XML est capable de traiter un message SOAP simple en 0,3 ms. Quant au 
debit de la plate-forme, il atteint plus de 100 000 messages/s lorsque le service et son client fonction- 
nent dans la meme JVM (Java Virtual Machine) et se maintient a plus de 700 messages/s lorsqu'ils 
communiquent sur le meme reseau local via deux JVM distinctes (performances mesurees par 
l'editeur sur un Dell Dimension XPS T600 - Pentium III 600 MHz). 

Le produit Glue est actuellement telechargeable en version 3.2.3 et 3.3bl. L'analyseur syntaxique 
Electric XML est egalement disponible separement en version 6.0.3 et 6.1bl. La version 3.2.3 de 
Glue prend en charge la specification Servlets 2.3, une nouvelle console graphique, une interface 
UDDI graphique et Fintegration JNDI. La version 4.0 integrera le support des transactions distri- 
buees. 
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Le portail de services Web XMethods et son annuaire UDDI prive 

II faut signaler que le site portail XMethods utilise depuis peu le serveur UDDI Glue pour permettre aux utilisateurs 
d'acceder aux services references par le site ou de publier leurs propres services (voir http://www.xmethods.net/ 
ve2/UDDI.po). II s'agit done d'une utilisation d'UDDI en annuaire prive qui permet aux utilisateurs d'XMethods de 
se passer des anciens formulaires de saisie au profit des outils standards de I'annuaire de The Mind Electric. 



Gaia 

Par ailleurs, The Mind Electric prevoit d'editer un second produit, dont le nom de code est Gaia (voir 
http://www.themindelectric.com/gaia/index.html). Ce nouveau produit est presente comme une alternative 
aux technologies J2EE et JINI de Sun Microsystems et permettra de combiner dans une nouvelle 
infrastructure la puissance des services Web et des architectures de grilles d'ordinateurs (grid compu- 
ting). Gaia permettra de gerer des services Web controles par toutes sortes de plates-formes et sera 
implemented de maniere native en technologies Java et .NET. Ce produit est en projet depuis 
plusieurs mois, mais n'est pas encore disponible. 

Cape Clear : CapeConnect et CapeStudio 

Cape Clear (http://www.capeclear.com) a ete creee en septembre 1999 par d'anciens responsables de 
IONA Technologies (http://www.iona.com), certains d'entre eux en sont egalement fondateurs. Parmi les 
fondateurs de Cape Clear et anciens de IONA, on peut titer Annrai O' Toole (ancien CTO ou Chief 
Technical Officer de IONA), David Clarke, Hugh Grant, John McGuire et Colin Newman. 

La societe est basee a Dublin pour l'Europe et a Campbell en Californie pour les Etats-Unis. 

CapeConnect 

Un an apres sa creation, en decembre 2000, Cape Clear a distribue la premiere version de sa plate- 
forme de deploiement et d' execution de services Web : CapeConnect One. 

Une seconde version, CapeConnect Two, est sortie peu de temps apres, en avril 2001, puis une troi- 
sieme version CapeConnect Three a ete disponible en octobre 2001 et a introduit la prise en charge 
de la specification UDDI et des serveurs Corba. 

La version CapeConnect 3.5 est disponible depuis mars 2002. L architecture technique du produit est 
decrite dans le document de presentation CapeConnect 3.5 Technical Overview (voir http://www. 
capeclear.com/products/whitepapers/CCThreeTechnicalOverview.pdf). 

A l'heure de la redaction de ces lignes, la version 4.0 est sur le point de sortir. Une version 4.0 beta 
peut etre telechargee a l'adresse http://www.capeclear.com/products/beta. Les caracteristiques de la plate- 
forme sont detaillees dans le document http://www.capeclear.com/products/whitepapers/CapeConnect4 
_whitepaper.pdf. Le produit de Cape Clear se rapproche de plus en plus de ce que Ton designe sous le 
nom de plate-forme d' integration EAI. Cette version integre notamment de nouvelles fonctions 
d' administration, la prise en charge de nouveaux protocoles de transport comme JMS par exemple, et 
de nouveaux adaptateurs. 
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CapeStudio 

Parallelement a la mise au point de cette plate-forme d' execution, Cape Clear s'est attachee a la 
production d'un nouvel environnement de conception, developpement, deploiement et test de servi- 
ces Web : CapeStudio, dont la premiere version est sortie en septembre 2001. 

La version CapeStudio 3.0 de ce produit est disponible depuis mars 2002. 

Le studio evolue egalement en meme temps que la plate-forme CapeConnect et une nouvelle version 
4.0 beta, groupee avec la plate -forme CapeConnect dans 1' ensemble CapeClear Product Set, est 
disponible a la meme adresse que celle mentionnee precedemment pour CapeConnect. 

La liste des fonctionnalites offertes par ces deux produits est exposee dans le document http:// 
www.capeclear.com/products/capestudio/features/features_list.pdf. 

CapeScience 

Cape Clear a egalement mis en place un site Internet de support et de ressources dediees aux archi- 
tectes et developpeurs. Le site de CapeScience est accessible a http://capescience.capeclear.com. 

En ce qui concerne les implementations Java utilisees par ses produits, Cape Clear a choisi de deve- 
lopper ses propres librairies et fait appel aux API SOAPDirect et UDDIDirect. Ces produits utilisent 
egalement les analyseurs syntaxiques Xerces et Xalan d' Apache. 

Systinet WASP Server for Java et WASP UDDI 

Systinet (voir http://www.systinet.com), initialement creee en mars 2000 sous le nom d'Idoox, a ete fondee 
par Roman Stanek, un ancien responsable de Sun Microsystems. Roman Stanek a ete auparavant le 
fondateur et PDG de NetBeans, avant le rachat de la societe par Sun Microsystems en octobre 1999. 

L environnement de developpement produit par cette societe a ensuite change de nom pour devenir le 
produit Forte for Java, puis plus recemment Sun ONE Studio. 

La societe est etablie a Cambridge (Massachusetts) et dispose d' implantations a San Francisco, 
Londres et Prague. 

Idoox a commence par editer un premier produit : IdooXoap, qui etait en fait une plate-forme 
d' execution SOAP. Puis une nouvelle version du produit, nommee WASP 1.0 (Web Applications and 
Services Platform), est sortie en mars 2001, avant que la societe ne devienne Systinet suite a une 
levee de fonds realisee en octobre 2001. Puis une version WASP Server 3.0 Server Advanced a ete 
publiee en novembre 2001. Cette version etait libre pour le developpement et les tests de logiciels. 

Enfin, il faut signaler la disponibilite d'un centre de ressources dedie aux developpeurs a l'adresse 

http://dev. systinet. com. 

WASP Server 

WASP Server constitue le produit historique de la societe. II se decline maintenant en deux versions : 

• WASP Server for Java ; 

• WASP Server for C++. 

Ces produits sont aujourd'hui disponibles en version 4.5. 
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La version C++ s'integre avec les serveurs Web IIS, Apache et Sun ONE Web Server (ex-iPlanet). 

La version Java peut fonctionner en mode autonome (standalone) ou etre incorporee dans les 
serveurs d' applications les plus courants tels que WebLogic, WebSphere, Sun ONE Web Server, 
Orion, JBoss ou Tomcat par exemple. 

WASP Server for Java utilise les implementations JAXM et JAX-RPC de Sun Microsystems. Le 
produit s'appuie egalement sur les analyseurs syntaxiques Xerces et Xalan de la communaute Apache. 

La version 4.5 de ces produits est disponible (versions C++ et Java telechargeables a http://www.systinet 
. com/products/download_center) . 

WASP UDDI 

WASP UDDI est le second produit apparu dans le catalogue de Systinet. La version disponible 
aujourd'hui est egalement la version 4.5. II s'agit d'une implementation d'annuaire UDDI prive qui 
incorpore la specification UDDI 2.0. Elle reste aussi compatible avec la specification UDDI 1.0. Elle 
incorpore egalement quelques caracteristiques de UDDI 3.0. 

WASP UDDI utilise le moteur d' execution SOAP WASP Server pour son propre fonctionnement. Le 
produit est done operationnel sur les memes serveurs d' applications que ceux qui sont deja pris en 
charge par WASP Server. 

Le serveur fonctionne avec les bases de donnees SQL Server, DB2, Oracle, Sybase, Cloudscape et 
PostgreSQL. 

La version 4.5 de Fannuaire WASP UDDI est disponible en telechargement a Fadresse http://www.systinet 
. com/products/download_center. 

WASP OEM Edition 

Les produits de la societe Systinet semblent rencontrer un certain succes dans le monde des techno- 
logies de services Web. Systinet a recemment annonce des accords d'OEM avec de grands acteurs du 
logiciel comme Mercator et Interwoven (voir annonce du 15 octobre 2002 : http://www.systinet.com/ 
news/latest_news/article&id_ele=24). La societe a done decide de mettre en place un programme dedie a 
ces partenariats OEM et de decliner le produit WASP Server dans une version dediee a ce type de 
clientele. 

Les ressources de la version WASP OEM Edition sont accessibles a Fadresse http://www.systinet.com/ 
products/wasp_oem/overview. 

WASP Developer 

Systinet s'est egalement attachee tres tot a fournir des outils de developpement adaptes a ses plates- 
formes (voir http://www.systinet.com/products/wasp_developer/overview). Ces outils se presentent sous la 
forme de modules enfichables (plug-ins) dedies aux plates-formes de developpement les plus impor- 
tantes du monde Java telles que : 

• Borland JBuilder ; 

• Sun ONE Studio ; 

• Eclipse et IBM WSAD. 
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Bowstreet Business Web Factory 

La societe Bowstreet (http://www.bowstreet.com), creee en 1999, a ete Fun des premiers editeurs a propo- 
ser une plate-forme de developpement et d' execution, apte a prendre en charge les services Web. Cet 
environnement est propose par le produit Business Web Factory. 

Bowstreet s'est egalement interessee aux portails Web et propose depuis le 8 octobre 2002 un 
nouveau produit : Portlet Factory for IBM WebSphere. 

Collaxa Web Service Orchestration Server 

Collaxa (http://www.collaxa.com), fondee a la fin de Fannee 2000, s'est specialisee dans la gestion des 
processus metier. Cette societe propose un produit, Web Service Orchestration Server (WSOS), dont 
la premiere version (1.0) s'appuyait sur une technologie originale baptisee ScenarioBeans, une forme 
d'abstraction proche de la philosophie des JavaServer Pages. Cette version initiale prenait en charge 
les specifications SOAP et WSDL et s'inspirait du protocole BTP. Seul le serveur d' applications 
BEA WebLogic 6. 1 etait pris en charge, ainsi que la base de donnees Oracle8 (et plus). 

Une nouvelle version du produit (2.0 beta) vient d'apparaitre au catalogue de Collaxa (voir http:// 
www.collaxa.com/product.welcome.html). Cette version est maintenant compatible avec la nouvelle specifi- 
cation BPEL4WS et les scenarios BPEL. Le nouveau serveur sera capable de fonctionner en grappe 
(cluster). Quatre declinaisons du produit sont prevues au jour ou nous redigeons cet ouvrage : 

• Collaxa for BEA WebLogic ; 

• Collaxa for IBM WebSphere ; 

• Collaxa for Oracle9i ; 

• Collaxa for Sun ONE. 

Ce produit utilise les analyseurs syntaxiques Xerces et Xalan d' Apache, le moteur d' execution 
Apache SOAP, ainsi que la librairie WSDL4J d'IBM. 

PolarLake Web Services Express 

PolarLake (voir http://www.polarlake.com) a ete fondee en 2001 a la suite d'un projet initie en 1999 par la 
societe XIAM (voir http://www.xiam.com), specialisee dans les systemes de messagerie mobile interactifs. 

La technologie PolarLake, Enterprise-strength XML Platform for Java, a ete initialement developpee 
par XIAM pour acceder au marche de F integration dans le monde de la technologie SMS (Short 
Messaging Service). Le developpement de cette plate -forme a ete poursuivi au travers de la creation 
d'une nouvelle societe, nominee PolarLake, dont Fobjectif est d'investir le marche beaucoup plus 
large de F integration de Fentreprise etendue. 

PolarLake s'est plus particulierement specialisee dans F edition de produits centres sur le monde 
XML, qui integrent notamment la technologie Dynamic XML Runtime, ainsi que le framework 
d' assemblage d' applications XML Circuits. 

Deux produits sont aptes a prendre en charge des services Web : 

• la plate-forme de deploiement PolarLake ; 

• F environnement de developpement rapide PolarLake Web Services Express. 
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II faut egalement remarquer la presence de deux autres produits au catalogue de PolarLake susceptibles 
d'etre interessants dans une optique d'integration : 

• l'integrateur de bases de donnees PolarLake Database Integrator : il permet l'integration de 
documents XML avec les bases de donnees relationnelles au niveau donnees (cartographie de 
type mapping) et au niveau traitement (definition, filtrage, transformation, division) ; 

• l'integrateur de messagerie PolarLake Messaging Integrator : au moment de la redaction de 
cet ouvrage, il est en cours de developpement, il sera capable d'abstraire le support des 
systemes de messagerie IBM WebSphere MQ, TIBCO Rendezvous, Microsoft MQ et Spirit- 
Soft SpiritWave, de meme que les protocoles HTTP, FTP et SMTP. 

PolarLake est egalement une societe basee a Dublin, et a des bureaux a Londres, Tokyo et New York. 

PolarLake 

Le produit PolarLake (voir http://www.polarlake.com/products/polarlake) est un moteur d' execution XML. 
Celui-ci comporte un module de conception, un module de surveillance et une console de gestion. 
Des modules enfichables (plug-ins) dedies aux plates-formes de developpement Java sont disponi- 
bles pour : 

• Borland JBuilder ; 

• Sun ONE Studio. 

Le moteur d'execution PolarLake prend en charge les specifications SOAP, WSDL et UDDI. II permet le 
deploiement dynamique de nouveaux services Web (approche top-down) ou 1' exposition de services Web 
qui encapsulent des classes Java et des composants EJB ou COM existants (approche bottom-up). 

PolarLake fonctionne soit en mode autonome sous Tomcat, soit deploye dans un serveur J2EE tel 
qu'IBM WebSphere ou BEA WebLogic. 

PolarLake Web Services Express (WSE) 

Le produit PolarLake Web Services Express (voir http://www.polarlake.com/products/polarlakewse) est un 
environnement de developpement et de deploiement rapide de services Web. Celui-ci s'appuie sur les 
fonctionnalites du serveur XML PolarLake. 

Ce produit permet de deployer rapidement un service Web a partir de F exposition d'un composant 
existant, via un guide de generation (wizard). WSE prend en charge notamment l'interoperabilite 
avec des clients SOAP .NET et Apache SOAP. 

AltoWeb Application Platform 

Alto Web (voir http://www.altoweb.com) a ete fondee par Ali Kutay, le premier PDG de BEA. Cette 
societe offre une plate-forme de developpement et de deploiement de services Web appelee AltoWeb 
Application Platform (voir http://www.altoweb.com/products/index.html). 

Cette plate-forme prend en charge les specifications SOAP, WSDL et UDDI. Elle peut fonctionner de 
concert avec les serveurs d' applications IBM WebSphere, BEA WebLogic et Tomcat/JBoss ainsi 
qu'avec les principales bases de donnees relationnelles : Oracle, SQL Server, DB2 et Sybase. 

AltoWeb est basee a Palo Alto en Californie. 
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Sonic XQ 

Sonic Software (voir http://www.sonicsoftware.com) est Tune des filiales de Progress Software (voir http:// 
www.progress.com), qui vient par ailleurs d'annoncer le rachat d'eXcelon (voir http://www.exln.com). 
Sonic Software a ete fondee en Janvier 2001 et s'est specialised dans les systemes de messagerie Java 
(JMS). La societe est deja connue pour son serveur de messagerie Sonic MQ. Ce serveur est par 
exemple utilise par le site d'XMethods pour prendre en charge le service Web de partage de donnees 
XSpace (voir http://www.xmethods.com/ve2/XSpace.po). 

Recemment, Sonic Software a propose une nouvelle plate-forme de deploiement de services Web, 
nommee Sonic XQ, qualifiee de « premier bus de services d'entreprise » ou ESB (Enterprise Service 
Bus), capable de fonctionner sur son serveur de messagerie Sonic MQ. Sonic XQ implemente egale- 
ment F architecture de connecteurs JCA. Elle prend en charge les specifications SOAP, WSDL et UDDI. 

Pour son fonctionnement, Sonic XQ s'appuie sur F implementation Apache SOAP, ainsi que sur 
Fanalyseur syntaxique XML Xerces de la communaute Apache. 

Sonic Software est egalement a Forigine de Fintroduction d'une fonction d'invocation asynchrone de 
services Web dans le moteur d' execution Axis 1.0 de la communaute Apache (voir annonce : http:// 
www. sonicsoftware. com/news/pressrelease_ 79963/pritem. ssp) . 

Notons enfin que le 9 Janvier 2003, Sonic Software, avec d'autres compagnies comme Fujitsu, Hita- 
chi, NEC, Oracle et Sun Microsystems, a publie une specification de fiabilite des echanges avec les 
services Web : WS-Reliability 1.0 (voir http://www.sonicsoftware.com/news/pressrelease_89565/pritem.ssp), 
qui repose sur une extension standard de SOAP 1.1. 

Sonic Software est basee a Bedford dans le Massachusetts. 

Les prochaines evolutions 

Des a present, il est possible de percevoir les prochains developpements auxquels vont se trouver 
meles les services Web, et plus particulierement les environnements Java. 

En effet, cette nouvelle forme d' architecture de systemes d' information, en anglais SOA (Service Orien- 
ted Architecture), evolue vers un point de confluence avec deux autres types d' architectures et nous allons 
vraisemblablement assister a un phenomene d'hybridation entre ces differentes technologies. II s'agit : 

• des architectures dites « d'egal a egal » ou de « pair a pair » (peer-to-peer), recemment popu- 
larisees par le reseau Napster et ses successeurs (bien que cette representativite soit quelque 
peu abusive) ; 

• des grilles informatiques (grid computing). 

Cette evolution se manifeste deja par F annonce de produits hybrides comme Gaia de The Mind Elec- 
tric ou bien la specification OGSA (Open Grid Services Architecture) du projet Globus et son imple- 
mentation de reference. 

Projet Gaia (The Mind Electric) 

Le projet Gaia de la societe The Mind Electric (voir http://www.themindelectric.com/gaia/index.html) vise a 
offrir une plate-forme de type grille informatique orientee services. Cette plate-forme prend en 
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charge les problematiques d'equilibrage de charge (load-balancing), de gestion de grappes de machines 
(clustering) et de reprises sur incidents (fail-over). 

Pro jet Globus (globus.org) 

Le projet Globus est un projet de recherche et developpement, initie en 1996, essentiellement mene 
par des chercheurs et universitaires du Laboratoire National Argonne (voir http://www-fp.mcs.anl.gov/ 
division/welcome/default.asp), une emanation du departement americain de l'energie, des universites de 
Chicago (voir http://www.cs.uchicago.edu), de Californie du Sud (University of Southern California 
Information Sciences Institute : http://www.isi.edu) et de l'lllinois Urbana-Champaign (National Center 
for Supercomputing Applications at the University of Illinois Urbana-Champaign : http:// 
www.uiuc.edu). D'importants partenaires industriels sont associes a ces developpements dont IBM, 
Microsoft, Cisco et la Nasa. Le projet s'est concretise par le developpement et la mise au point d'une 
boite a outils Globus Toolkit (voir http://www.globus.org/toolkit/default.asp), essentiellement ecrite en 
langage C et actuellement disponible en version 2.2 sous licence publique Globus Toolkit. II existe 
egalement une premiere version commerciale de cette boite a outils, proposee depuis fevrier 2002 par 
la societe canadienne Platform (voir annonce : http://www.platform.com/newsevents/pressreleases/2002/ 
globus_ 19_02_02.asp). 

Projet OGSA (globus.org) 

La prochaine evolution de ce projet s'oriente vers une integration des concepts et des technologies de 
grilles informatiques et de services Web. Cette evolution, nommee OGSA, a ete specifiee initialement 
par les membres du projet Globus et par IBM. La derniere evolution de cette specification Grid 
Service Specification est datee du 5 fevrier 2003 (voir http://www.gridforum.org/ogsi-wg/drafts/draft-ggf-ogsi- 
gridservice-1 1_2003-02-05.pdf). Cette nouvelle version devrait aboutir en 2003 a la sortie de la 
version 3.0 du Globus Toolkit. Les informations relatives a cette nouvelle evolution du projet Globus 
sont disponibles a l'adresse http://www.globus.org/ogsa. La nouvelle specification a ete soumise au 
Global Grid Forum (voir http://www.gridforum.org) pour discussion. Sa partie infrastructure sera plus 
particulierement prise en charge par le groupe de travail OGSI-WG (Open Grid Services Infrastructure 
Working Group) : http://www.gridforum.org/ogsi-wg. Cette specification s'appuie sur les specifications SOAP, 
WSDL et WSIL (WS-Inspection). 

Une premiere implementation de reference de la specification Grid Service Specification a ete ecrite 
en Java (voir http://www.globus.org/ogsa/deliverables/prototype.html). Une autre implementation en 
langage C est egalement prevue. En outre, une integration plus etroite avec les environnements J2EE 
et .NET est au programme. Une premiere demonstration de cette implementation de reference, qui 
utilise le moteur d' execution Axis SOAP de la communaute Apache, couple a un environnement JSP/ 
Servlets Tomcat ou a un environnement d'execution autonome, a ete presentee a l'exposition Globus 
Tutorial de Chicago qui s'est tenue de fin Janvier a debut fevrier 2002 (voir http://www.globus.org/about/ 
events/USJutorial/index.html). Une premiere version publique (OGSI Technology Preview release) peut 
etre telechargee depuis le 17 mai 2002. Depuis fevrier 2003, la cinquieme version est telechargeable 
(voir http://www.globus.org/ogsa/releases/TechPreview/index.html). 
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Sites de reference et ressources 
Apache 

• Analyseur syntaxique XML Xerces 1 : http://xml.apache.org/xerces-j/index.html 

• Analyseur syntaxique XML Xerces 2 : http://xml.apache.org/xerces2-j/index.html 

• Analyseur syntaxique XSL Xalan 2 : http://xml.apache.org/xalan-j/index.html 

• Implementation SOAP (ex-IBM SOAP4J) : http://xml.apache.org/soap/index.html 

• Implementation SOAP Axis : http://xml.apache.org/axis/index.html 

BEA-WebGain 

• BEA Web Services : http://www.bea.com/products/webservices 

• BEA Web Services Technology Track : 

http://dev2dev.bea.com/techtrack/detail.jsp?forum=4&highlight=webservices 

• BEA Workshop : http://www.bea.com/products/webiogic/workshop 

• WebGain Studio : http://www.webgain.com/products 

Borland 

• Borland Web Services : http://www.borland.com/webservices 

• Borland Web Services Kit for Java : http://www.borland.com/jbuilder/webservices 

Cape Clear 

• Site de Cape Clear : http://www.capeciear.com 

• CapeConnect : http://www.capeclear.com/products/capeconnect 

• CapeStudio : http://www.capeclear.com/products/capestudio 

• Ressources developpeurs CapeScience : http://www.capescience.com 

Divers editeurs 

• Actional Web Services Management Platform : http://www.actional.com/products/web_services 

• Epicentric Foundation Server & Builder : http://www.epicentric.com/solutions/products.jsp 

• Fujitsu Interstage i-Flow : http://www.i-flow.com 

• Infravio Web Services Management System : http://www.infravio.com/solutions/wsms.html 

• Instantis Site Wand : http://www.instantis.com/products/products_home.html 

• Jacada Integrator : http://www.jacada.com/Products/Jacadalntegrator.htm 

• Killdara Vitiris : http://www.killdara.com/products/vitiris 



IBM 
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Liberty Alliance : http://www.projectliberty.org 

Talking Blocks Web Services Management System : http://www.talkingblocks.com/products.htm 



Site alphaWorks : http://www.aiphaworks.ibm.com 

Site developerWorks : http://www-106.ibm.com/developerworks/webservices 

SOAP for Java : http://www.aiphaworks.ibm.com/aw.nsf/bios/soap4j 

WSDL Toolkit : http://www.alphaworks.ibm.com/tech/wsditooikit 

Web Services Toolkit : http://www.alphaworks.ibm.com/tech/webservicestoolkit 

XML and Web Services DE : http://www.alphaworks.ibm.com/tech/wsde 

Business Process Execution Language for Web Services Java Run Time (BPWS4J) : http:// 
www.aiphaworks.ibm.com/tech/bpws4j 

Web Services experience Language (WSXL) SDK : http://www.alphaworks.ibm.com/tech/wsxlsdk 

Web Services Gateway : http://www.alphaworks.ibm.com/tech/wsgw 

Web Services Hosting Technology : http://www.alphaworks.ibm.com/tech/wsht 

Web Services Invocation Framework (WSIF) : http://www.alphaworks.ibm.com/tech/wsif 

Web Services PMT (Process Management Toolkit) : http://www.alphaworks.ibm.com/tech/wspmt 

WebSphere SDK for Web Services : http://www-106.ibm.com/developerworks/webservices/wsdk 

WebSphere UDDI Registry : http://www.alphaworks.ibm.com/tech/UDDIreg 

IONA 

• Site general : http://www.iona.com 

• Orbix E2A XMLBus Edition : http://www.iona.com/products/webserv-xmlbus.htm 

• Site Developpeur XMLBus Edition : http://www.xmlbus.com 

• XMLBus Edition Web Services Interoperability Forum : http://www.xmlbus.com/interop 

Globus Project 

• The Globus Project : http://www.globus.org 

• Open Grid Services Architecture (OGSA) : http://www.globus.org/ogsa 

• Open Grid Service Infrastructure Working Group (OGSI-WG) : http://www.gridforum.org/ogsi-wg 

• Globus Tutorial January 28 - February 1, 2002 : http://www.giobus.org/about/events/US_tutorial/ 
index.html 

• Globus Tutorial - Globus Toolkit Futures : An Open Grid Services Architecture : http:// 
www.globus.org/about/events/US_tutorial/slides/Dev-07-DataManagement1.ppt 

• OGSI Technology Preview Release : http://www.globus.org/ogsa/releases/TechPreview/index.html 
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Hewlett-Packard 



hp web services platform 2.0 : http://www.hpmiddleware.com/SalSAPI.dll/SaServletEngine.class/products/ 
hp_web_services/default.jsp 

hp web services registry 2.0 : http://www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/ 
hp_web_services/registry/default.jsp 

hp web services transactions 1.0 : http://www.bluestone.com/SalSAPI.dll/SaServletEngine.class/products/ 
webservicesjransactions/default.jsp 



JCP 



Site JCP : http://www.jcp.org 

Liste des Java Specification Requests (JSR) : http://www.jcp.org/jsr/all/index.en.jsp 
JSR109 - Implementing Enterprise Web Sendees : http://www.jcp.org/jsr/detaii/109.jsp 
JSR1 10 - Java APIs for WSDL (JWSDL) : http://www.jcp.org/isr/detaWI W.jsp 
JSR031 - JAXB (Java API for XML Binding) : http://www.jcp.org/jsr/detail/31.jsp 
JSR067 - JAXM (Java API for XML Messaging) : http://www.jcp.org/jsr/detail/67.jsp 
JSR063 - JAXP (Java API for XML Processing) : http://www.jcp.org/jsr/detail/63.jsp 
JSR093 - JAXR (Java API for XML Registries) : http://www.jcp.org/jsr/detail/93.jsp 
JSRIOl - JAX/RPC (Java API for XML based RPC) : http://www.jcp.org/jsr/detail/101.jsp 

Novell (ex-SilverStream) 

• Site general : http://www.novell.com 

• Site exteNd : http://www.silverstream.com/Website/app/en_US/Extend 

• Site exteNd Composer : http://www.silverstream.com/Website/app/en_US/Composer 

• Site exteNd Workbench : http://www.silverstream.com/Website/app/en_US/Workbench 

• Site exteNd jBroker : http://www.silverstream.com/Website/app/en_US/JBroker 

• Site DevCenter : http://devcenter.silverstream.com/DevCenter/DevCenterPortal?PID=DevCenter.html 

Oracle 

• Site general : http://www.oracle.com 

• Site Technology Network : http://otn.oracle.com 

• Site Web Services Technology Center : http://otn.oracle.com/tech/webservices/content.html 

PolarLake 

• Site general : http://www.polarlake.com 

• Produit PolarLake : http://www.polarlake.com/products/polarlake 

• Produit PolarLake Web Services Express : http://www.polarlake.com/products/polarlakewse 
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Sun Microsystems 

Site de reference Sun ONE : http://wwws.sun.com/software/sunone (ex-site http://www.sun.com/software/ 
sunone) 

Site Dot-Com Builder : http://dcb.sun.com 

Site Java Technology & Web Services : http://java.sun.com/webservices/index.html 

Site Java Technology & XML : http://java.sun.com/xml 

Site JAX Pack : http://java.sun.com/xml/jaxpack.html 

Java API for XML-based RPC (JAX-RPC) Home Page : http://java.sun.com/xml/jaxrpc 

Java API for XML Messaging (JAXM) Home Page : http://java.sun.com/xml/jaxm 

Java API for XML Processing (JAXP) Home Page : http://java.sun.com/xml/jaxp 

Java API for XML Registries (JAXR) Home Page : http://java.sun.com/xml/jaxr 

Java Architecture for XML Binding (JAXB) Home Page : http://java.sun.com/xml/jaxb 

Site Java Web Services Developer Pack (Java WSDP) : http://java.sun.com/webservices/ 
webservicespack. html 

Sun ONE Starter Kit : http://wwws.sun.com/software/sunone/starterkit 

Systinet (ex-ldoox) 

• Site general : http://www.systinet.com 

• Site WASP Developer : http://www.systinet.com/products/wasp_deveioper/overview 

• Site WASP Server for Java : http://www.systinet.com/products/waspjserver/overview 

• Site WASP UDDI : http://www.systinet.com/products/wasp_uddi/overview 

• Site Developers' Corner : http://dev.systinet.com 

The Mind Electric 

• Site general : http://www.themindeiectric.com 

• Site Glue : http://www.themindelectric.com/glue/index.html 

• Site Gaia : http://www.themindelectric.com/gaia/index.html 

• Site Electric XML : http://www.themindelectric.com/exml/index.html 

• Attention au GLOUBIBOULGA , il peut mordre ! 
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La plate-forme .NET 



Ce chapitre a pour objectif de decrire les technologies des services Web mises en ceuvre par Micro- 
soft sur la plate-forme .NET. 

Microsoft, nous l'avons vu, joue depuis le depart un role tres important dans la specification et la 
normalisation des technologies des services Web. Mais au-dela de cette contribution, F implication de 
Microsoft s'est tres vite traduite dans les faits par la mise en ceuvre de composants executables et 
d'outils de developpement permettant de passer de la theorie a la pratique. Des mai 2000, un SDK 
pour Visual Studio 6 est disponible gratuitement et permet aux developpeurs Visual Basic ou C++ 
d'ecrire leurs premiers services Web. Ce SDK comprend : 

• cote serveur, un listener ASP et un utilitaire permettant de creer un document WSDL a partir de 
tout composant COM ; 

• cote client, un controle ActiveX specifique permettant de « consommer » tout service. 

La sortie de Visual Studio.NET beta 2 (version 7) en juin 2001 est encore plus significative : TIDE 
offre des outils qui permettent d'atteindre une productivite tres importante : 

• dans le developpement d'un nouveau service ; 

• dans la mise en ceuvre d'une interface de services Web a partir d'une application existante ; 

• dans 1' integration (« consommation ») de services Web, tache rendue aussi simple que F integra- 
tion de composants ActiveX classiques. 

En fait, les services Web sont la composante essentielle de la strategie .NET de Microsoft : « De 
maniere assez simple, .NET est la plate-forme de Microsoft dediee aux services Web XML. (...) La 
plate-forme .NET de Microsoft comprend une famille de produits batis autour d'XML et des stan- 
dards industriels dTnternet, qui couvre tous les aspects du developpement, de la gestion, de Fusage 
courant ou de F experimentation des services Web XML » (traduction de Fauteur, site de Microsoft 
fin 2002). 
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Annoncee officiellement en juin 2000, la strategie .NET de Microsoft est un projet d'une envergure 
sans doute comparable au developpement de Windows dans les annees quatre-vingt-dix. Et il faut 
bien parler de strategie car il ne s'agit pas de developper un produit ou meme une ligne de produits 
mais d'axer tous les developpements de la societe vers un objectif global qui correspond a une 
nouvelle vision de Finformatique distribuee et cooperante (les logiciels deviennent des services). Le 
projet est ambitieux et fait evidemment couler beaucoup d'encre. 

Dans les faits, la strategie .NET s'articule autour de trois axes (voir figure 15-1) : 

• Les produits Serveur d'Entreprise .NET: 

lis regroupent tous les logiciels serveur de Microsoft : SQL Server 2000, Exchange 2000, BizTalk 
Server, Commerce Server, etc. Tous ont evolue et prennent ou prendront en charge XML et les 

services Web. 

Si Exchange et SQL Server sont des logiciels bien connus dans le monde Microsoft, il n'en est pas 
de meme pour BizTalk Server. Pourtant, cet outil occupe une place preponderante dans ce grand 
ensemble puisqu'il est dedie aux problemes d'echanges de donnees (EDI, XML) et d'orchestration 
(flux de donnees y compris a faible couplage). 

• Le framework .NET et les outils : 

Le framework .NET, que nous allons presenter en detail dans ce chapitre, est la nouvelle plate-forme 
de developpement et d' execution de Microsoft. Cette plate-forme est par ailleurs la cible principale 
de la nouvelle version de Visual Studio, Fenvironnement de developpement de Microsoft. 

• Les services Web de base regroupes dans le cadre du projet Hailstorm : 

Les services Web de base que Ton nomme aussi .NET MyServices, sont constitues d'une gamme 
de services Web offrant des fonctions essentielles comme 1'authentification avec Microsoft Pass- 
port ou un camet d'adresses avec HotMail. Cela est done la preuve tangible que des services Web 
peuvent etre developpes et utilises par n'importe qui pour repondre a une demande de service. 



Hailstorm 

Le projet Hailstorm a ete officiellement abandonne par Microsoft en avril 2002 (voir la section « .NET MyServices ») 



Visual Studio. Net 



Framework .Net 



Serveurs Entreprise .Net 



.Net 
MyServices 



Systeme d'exploitation (com+, mts, msmq, etc.) 



Figure 15-1 

L' architecture strategique .NET de Microsoft. 
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Le framework .NET 

Notre objectif n'est pas de faire une presentation detaillee du framework .NET dans son integralite, 
mais d'en decrire les grandes lignes. Les fonctions et les composants qui touchent directement les 
technologies des services Web seront abordes plus en detail dans les sections suivantes. 

Le framework .NET est la nouvelle plate -forme logicielle de Microsoft qui permet de construire, de 
deployer et d'executer des services Web et des applications qui les utilisent (voir figure 15-2). Cette 
plate-forme est en principe independante des outils de developpement, meme s'il faut reconnaitre 
que Visual Studio .NET est le seul a 1' exploiter pleinement (rien ne vous empeche d'utiliser un 
simple editeur de texte et d'appeler le compilateur en ligne de commande). 

Au-dela de la prise en charge des services Web, la plate-forme est censee repondre a tous les besoins 
des developpeurs, c'est-a-dire qu'elle permet de developper des applications Internet mais aussi des 
applications classiques s'executant sur Windows (ou, en principe, tout systeme d' exploitation 
prenant en charge le framework .NET). 
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Systeme d'exploitation (com+, mts, msmq, etc.) 



Figure 15-2 

Architecture du framework .NET. 



Le framework .NET est constitue de quatre composants principaux que nous allons decrire en detail 

• une machine virtuelle appelee CLR (Common Language Runtime) ; 

• un ensemble hierarchise et unifie de librairies objets (.NET Framework Class Library) ; 

• un environnement d' execution d' applications et de services Web (ASP .NET) ; 

• un environnement d'execution d' applications graphiques « natives » (Win Forms). 



Processus de normalisation de I'environnement .NET 

Voir la section « .NET » du chapitre 13 « Principes de mise en oeuvre ». 
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La librairie objet et, plus generalement, le framework, ont ete concus pour prendre en charge diffe- 
rents scenarios de developpement s'appliquant a des objets techniques de differents types : 

• des applications en mode console ; 

• des applications interpretees en mode script ; 

• des application graphiques GUI (Windows Forms) ; 

• des applications orientees Internet (Web Forms) ; 

• des services Web ; 

• des composants Windows. 

Nous allons bien evidemment nous interesser uniquement aux applications Internet et aux services 
Web : ces deux types d' applications sont developpes et executes dans le cadre du nouvel environnement 
ASP.NET de Microsoft. 

Le CLR (Common Language Runtime) 

De la meme maniere qu'il existe une machine virtuelle pour Java ou Smalltalk, les applications .NET 
disposent d'un moteur d'execution appele CLR pour Common Language Runtime (voir figure 15-3). 



CLR - Common Language Runtime 



Compilateur 



Gestionnaire memoire 



Securite 



CLS - Common Language Specification 



Loader 



Figure 15-3 

U architecture generate du Common Language Runtime. 



Un environnement d'execution specifique 

Le CLR fournit une couche d'abstraction par rapport au systeme d' exploitation. II se charge de gerer 
l'execution du code et de fournir des services (voir figure 15-3). 
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Le code source d'un programme destine a fonctionner avec le CLR est appele managed code (code 
gere ou dirige). Cela signifle simplement que le programme delegue au CLR la responsabilite des 
taches telles que le chargement et F installation du code executable, la creation d'objets, la gestion 
automatique de la memoire (allocation et nettoyage automatique ou garbage collector), les appels de 
methodes, les fonctions de securite, etc. 

Le fonctionnement du CLR repose sur des choix techniques tout compte fait assez classiques, quoi- 
que jamais appliques a un projet de cette envergure : 

• le code source de F application est compile dans un langage intermediaire qu'on appelle le Micro- 
soft Intermediate Language (MSIL) et qui est independant d'une part du langage source et de 
F autre de la plate-forme d' execution ; 

• lors du premier appel, le code intermediaire est traduit a la volee, par un compilateur JIT (Just In 
Time), en code machine specifique a Fenvironnement d'execution (OS, CPU), puis charge et 
installe pour execution. 

Independance et interoperabilite des langages 

Une specificite du CLR, qui explique son nom, concerne son independance vis-a-vis du langage. La 
principale difference sensible par rapport a des machines virtuelles monolangage, comme celles 
sous-jacentes a Java et Smalltalk, est que le CLR fournit des services a des programmes ecrits dans 
differents langages de programmation (en mars 2003, on enumere vingt-quatre langages pris en 
charge par le CLR ; voir la section « Les langages du framework et C# »). Microsoft fournit Visual 
Basic, C#, C++, Jscript et J# et des editeurs tiers fournissent des compilateurs pour Cobol, Perl, 
Eiffel, Smalltalk, Scheme, etc. (voir http://msdn.microsoft.com/vstudio/partners/language/default.asp) 

Au-dela de Futilisation de langages multiples, le CLR rend possible Y interoperabilite entre ces 
langages. En void quelques exemples : 

• une classe ecrite en C++ peut heriter des methodes d'une classe ecrite en Visual Basic.NET ; 

• une classe ecrite en C# peut intercepter et traiter des exceptions issues de code Cobol ; 

• le debogage et le profilage d'un programme dont les composants sont ecrits dans des langages 
differents est possible dans un environnement unifie. 

Cette veritable integration de programmes ecrits dans des langages differents est rendue possible 
parce que : 

• Le MSIL permet de prendre en compte toutes les fonctionnalites des langages orientes objet (heri- 
tage, polymorphisme, etc.) ou non orientes objet, ainsi que des fonctions de bas niveau qui permet- 
tent d'optimiser des langages particuliers (Scheme ou Prolog). 

• Tous les langages prennent en charge un ensemble de fonctions communes, defini par une specifi- 
cation appelee Common Language Specification (CLS). Cette specification permet par exemple a 
Visual Basic.NET d'etre au meme niveau fonctionnel que C++ managed. Mais la conformite des 
programmes au CLS est du ressort des developpeurs et elle n'est obligatoire que lorsqu'il y a une 
necessite d' interoperabilite et d'ouverture. 

• II existe un systeme de type commun, le Common Type System (CTS), qui definit un systeme stan- 
dard de types ainsi que les regies pour creer de nouveaux types derives. Ce systeme non seulement 
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facilite F implementation de nombreux langages (du Cobol au C++) mais permet aussi de deleguer 
la creation et la gestion des types de donnees au CLR. 

• II existe des informations de description, les metadonnees, qui permettent au CLR de prendre 
connaissance du contenu des programmes en termes de classes, de types, d'heritage, etc. Ces infor- 
mations ont un format normalise a l'execution, independant du langage d' implementation du 
programme, et peuvent done etre utilisees et manipulees par d'autres programmes, et notamment 
par les outils de Fenvironnement de developpement. 

Les assemblages 

Le framework .NET introduit le concept d' 'assemblage, qui elargit la notion de composant que Fon 
trouve dans F architecture COM+. 

Un assemblage regroupe : 

• un manifest ; 

• des metadonnees, qui decrivent en particulier les types definis par F assemblage ; 

• du code MSIL ; 

• un ensemble de res sources (facultatif). 

Ces elements peuvent etre regroupes dans un fichier unique (un . exe ou .dll) ou dans des fichiers 
multiples comme des modules de code compile ( .netmodule) ou des fichiers de ressources ( . jpg, 
. bmp, etc.). Le decoupage en plusieurs fichiers peut, par exemple, permettre d'optimiser le telecharge- 
ment de Fapplication puisque le framework ne charge les fichiers (modules ou ressources) que lors- 
que cela est necessaire. Ces fichiers ne sont pas lies physiquement mais uniquement de facon logique 
par le biais du manifest. 

Les fonctions d'un assemblage sont les suivantes : 

• organiser le code que le CLR peut executer via le manifest de description et un point d'entree 
unique (Dll Main, WinMain ou Main) ; 

• definir un perimetre de securite a Finterieur duquel certains controles sont effectues ; 

• definir des types : la definition d'un type comprend obligatoirement Fassemblage qui l'imple- 
mente ; 

• definir un espace de references : les metadonnees du manifest decrivent a la fois les types et les 
ressources que Fassemblage expose, ainsi que les assemblages dont il depend ; 

• definir F unite a laquelle on peut attribuer un numero de version a l'execution ; 

• constituer une unite de deploiement. 
Enfin, un assemblage peut etre : 

• statique, a savoir memorise sur disque et chargeable a partir de celui-ci ; 

• ou bien dynamique, e'est-a-dire cree directement en memoire grace a l'API Aw framework (voir la 
documentation de System. Reflection) et immediatement executable. 



La plate-forme .NET 

Chapitre 15 

Les metadonnees et le deploiement 

Nous avons parle a plusieurs reprises des metadonnees : en tant que facteur cle de l'interoperabilite 
des langages mais aussi dans le cadre des manifests qui permettent la description des assemblages. 
Une consequence directe de ces manifests concerne le deploiement. En effet, ces informations de 
description sont systematiquement ajoutees aux assemblages lors de la compilation : le fichier resul- 
tant s'autodecrit, c'est-a-dire qu'il contient a la fois 1' implementation et la definition. De cette 
maniere, plus de fichier IDL comme c'etait le cas avec COM ou d'inscription en base de registre : on 
parle alors de « XCopy-Setup » c'est-a-dire d' installation par simple copie de fichier ! 

En termes de deploiement, ces metadonnees permettent done de resoudre un probleme majeur lie aux 
versions des programmes et qui est bien connu des developpeurs Windows sous le nom de DLL Hell, 
en francais Fenfer des DLL ! En effet, non seulement le CLR est capable de lire les metadonnees 
pour connaitre les dependances d'une application, mais il peut egalement executer simultanement 
plusieurs versions d'un meme assemblage pour satisfaire aux regies de dependances definies par 
plusieurs applications. 

En resume : 

• une application .NET s'installe par simple copie de fichiers ; 

• l'integrite du systeme est garantie puisque chaque application peut disposer de ses propres 
versions de composants et que les differentes versions peuvent etre executees simultanement. 

Un grand pas en avant a ete fait, e'est indeniable. Mais une telle simplicite de deploiement n'est 
envisageable que s'il existe en parallele une gestion de la securite qui permet de proteger autant 
que possible un systeme des assemblages douteux pousses par des developpeurs incompetents ou 
indelicats. 

La gestion de la securite 

La gestion de la securite est directement integree au CLR et s'effectue a deux niveaux : 

• au niveau du code, ou il s'agit de controler les droits d'acces du code par rapport aux ressources 
protegees et a certaines operations du systeme ; 

• au niveau de l'utilisateur, oil il s' agit alors de controler les droits d'un utilisateur en fonction de son 
identite et/ou de son profil. 

Ce deuxieme niveau est tres classique : il s'agit d'identifier l'utilisateur a partir de son login systeme 
ou d'une authentification specifique, et de lui attribuer des droits en fonction de son identite et de son 
profil. 

Mais ce controle peut s'averer totalement insuffisant car il arrive bien souvent que des utilisateurs 
executent des programmes dont ils ne connaissent pas l'origine (par exemple des pieces attachees 
recues par mail). Et quand bien meme cette origine est connue, l'utilisateur n'est pas capable de 
s'assurer de l'integrite du programme d' origine (qui a pu etre modifie par un virus) ou de verifier 
1' absence de dysfonctionnements qui pourraient s'averer particulierement dommageables. 

On comprend done tout l'interet du premier niveau de controle qui permet de definir precisement les 
droits d'un programme, c'est-a-dire les ressources auxquelles le code peut acceder et les operations 
qu'il a le droit d'executer. 
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Dans le detail, ce controle de securite du code permet : 

• de definir des permissions qui donnent des droits d'acces a differentes ressources du systeme ; 

• de definir une politique de securite qui consiste a associer ces permissions a des programmes ; 

• de requerir des permissions pour un programme en precisant lesquelles sont necessaires pour 
assurer son fonctionnement, ainsi que d'etablir les permissions qu'il serait utile d' avoir et celles 
qu'il ne doit pas avoir ; 

• de deleguer des droits a chaque assemblage charge, en s'appuyant sur les permissions requises par 
le programme et les operations permises par la politique de securite ; 

• de permettre a un programme de s' assurer que les programmes qui l'appellent disposent de droits 
specifiques ; 

• de permettre a un programme de s'assurer que les programmes appelants disposent d'une signature 
electronique (ce qui permet de limiter les appels a ceux d'une societe ou d'un site specifique) ; 

• d'imposer des restrictions aux programmes au moment de F execution, en effectuant un controle au 
niveau de la pile d'appel. 

Ces contraintes doivent etre prises en compte par le developpeur, qui : 

• soit s' assure des le lancement du programme que les droits necessaires sont acquis ; 

• soit gere les exceptions qui pourraient survenir au cours de F execution du fait d'une restriction 
d'acces. 

Les attributs 

Le framework .NET introduit une technique de parametrage et de scripting des applications par anno- 
tation : les attributs. Nous considerons qu'ils vont se reveler rapidement incontournables dans le 
cadre du developpement de services Web et, de maniere generate, dans le cadre du developpement 
des applications. 

Les attributs sont des mots-cles places au niveau des instructions de declaration qui permettent 
d'etendre la description des types, des champs, des proprietes, des methodes, etc. 

Le principe n'est pas completement nouveau, il se rapproche de ce qui est fait en Visual Basic ou 
en C++ en decrivant une methode comme etant publ i c ou pri vate. En revanche, certaines caracte- 
ristiques sont radicalement nouvelles : 

• les attributs sont une source d'information qui vient s'ajouter et s'associer aux declarations du 
code source ; 

• il est possible de creer ses propres attributs (en heritant de la classe System. Attribute), en plus des 
attributs predefinis ; 

• les attributs peuvent etre interroges par F application durant l'execution. 

Ces attributs sont utilises par le framework .NET pour de multiples raisons : la serialisation des 
objets, la securite, les transactions (MTS), mais aussi Fauteur d'un code source, Fespace de noms 
d'un service Web, etc. lis sont utilises a la fois comme elements de description du code source mais 
aussi pour modifier le comportement du programme en execution. 
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L'exemple le plus frappant est qu'il suffit de placer l'attribut [WebMethod] devant une methode publique 
pour l'exposer comme une interface de service Web. 

Un exemple d' annotation du code via les attributs est le suivant : il est par exemple possible de creer un 
attribut Hel pAttri bute qui permettrait de specifier pour chaque classe une URL de documentation : 

[Hel pAttribute( "HTTP: //www. eyrol les.com/MaClassInfo.htm")] 

class MaClass 

{ 

) 

A la compilation, ces attributs sont convertis en MSIL et enregistres avec les metadonnees. lis sont 
alors accessibles. Le CLR et des outils specifiques peuvent y acceder, ainsi que 1' application, a 
travers le service de Reflection (par exemple avec la methode GetCustomAttributesO de la classe 
System. Refl ect ion. Member Info) 



Lecture dynamique des attributs par les programmes 

Les classes de I'espace de noms Refl ecti on , System. Type et System. TypedRef erence permettent entre autres 
d'obtenir toutes les caracteristiques des assemblages charges en memoire. Parmi les informations disponibles figure 
la valeur des attributs. 



Conclusion 

Lapproche CLR se distingue sur d' autres plans d'approches que Ton peut considerer comme etant 
comparables, comme la JVM. Par exemple, la portabilite des applications et du framework .NET ne 
semble pas etre un objectif du CLR. D'abord parce que Microsoft souhaite privilegier ses systemes 
d' exploitation : pour le moment, le CLR n'est « portable » que sur les differentes versions de 
Windows : 9x, Me, NT4, 2000 et XR Meme si F infrastructure CLI a ete normalisee par un organisme 
independant (voir http://msdn.microsoft.com/net/ecma/) et si quelques projets de developpement de logi- 
ciels libres ont demarre en ayant pour objectif de porter le framework .NET sur differentes distribu- 
tions de Linux, il reste a prouver dans les faits que ces portages seront une alternative effective au 
CLR en environnement Microsoft. Qui plus est, la difficulte ne reside pas tant dans le portage du 
CLR que dans la compatibilite et la prise en charge de la librairie objet (en particulier pour les classes 
d'interfaces graphiques de System. windows. Forms). 

En revanche, il est certain qu'une approche similaire a celle de la machine virtuelle permet de simpli- 
fier le developpement des applications puisque le CLR prend en charge un certain nombre de taches 
importantes (comme la gestion de la memoire) et propose en outre des « services » interessants aux 
applications. II en decoule un gain de productivite et de fiabilite majeur (argument qui explique entre 
autres le succes de Java). 

D' autres avantages distinctifs de la CLR sont la simplification radicale du deploiement des applica- 
tions (voir la section « Les metadonnees et le deploiement ») ainsi qu'une gestion adaptee et souple 
de la securite. 

Lorsque tous les postes Windows disposeront (a terme) du CLR, il est possible d'imaginer que le 
modele actuel de client leger (c'est-a-dire utilisant un navigateur Internet) puisse etre remis en cause 
et remplace en tout ou partie par des clients .NET. II s'agit de la realisation par d'autres moyens du 
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projet imagine par Sun avec les applets Java. Mais il nous semble que, du fait que Microsoft maitrise 
le poste de travail, ce projet ait plus de chance de reussir. 

Evidemment, une grande partie du pilotage et du parametrage des services et des fonctions du CLR 
sont pris en charge automatiquement par les outils de developpements (IDE, compilateurs) et sont 
pour ainsi dire transparents pour le developpeur. 

La librairie objet (Framework Class Library) 

La librairie objet du framework .NET est un ensemble de classes, d'interfaces et de types predefinis 
inclus dans le SDK associe au framework. Cette librairie fournit les fondations de toutes les applications 
developpees dans Fenvironnement .NET. 

Le concept de librairie n'est pas nouveau dans l'environnement Microsoft (MFC, ATL, run-time C, 
Visual Basic, ou encore l'API Win32). Microsoft a su tirer les enseignements du passe et cette 
nouvelle librairie apporte de nombreuses ameliorations : 

• Elle offre un modele de programmation coherent puisque tous les services sont accessibles a partir 
d'une librairie orientee objet unifiee ; il n'est plus necessaire, par exemple, de melanger des appels 
a l'API Win32 avec l'utilisation d'objets COM. 

• Elle permet d'acceder aux fonctionnalites du CLR (Reflection) ainsi qu'a un ensemble conse- 
quent de services de complexite variable (gain de productivite). 

• Elle simplifie le developpement en ajoutant une couche d' abstraction consequente. Tous les 
services d' infrastructure les plus complexes (multithreading, gestion des transactions, etc.) 
peuvent etre mis en ceuvre a moindre frais. 

La librairie couvre un ensemble tres vaste de sujets, comme le montre la figure 15-4, et il est certain 
que la maitrise de cette librairie constitue la plus grosse difficulte pour les developpeurs qui decouvre 
le framework .NET 



La librairie objet du Framework .Net 



Classes Web (ASP.Net) 

Controle, cache, session, 

services Web, etc. 



Windows Forms 
Design, composants etc. 



Donnees 
ADO. Net, SQL, Types, etc. 



XML 
XSLT, XPath, Serialisation, etc. 



Classes systeme 
Collections, diagnostic, 10, securite, Thread, reflexion, etc. 



Services entreprise 

Transactions, MSMQ, 

etc. 



Figure 15-4 

La structure de librairie du framework .NET. 
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Les espaces de noms (namespaces) 

Tous les objets de la librairie, ainsi que tous ceux qui sont developpes dans le cadre d'une application 
sont nommes dans des espaces de noms (ou namespaces). Comme leur nom Findique, ces espaces 
definissent des contextes de nommage, dans lesquels il ne doit pas y avoir d'ambiguites de noms pour 
les classes, les interfaces et les types qui y sont definis. Ce mecanisme offre beaucoup de souplesse 
au developpeur qui est libre de nommer comme bon lui semble ses propres objets dans son propre 
espace. 

Les espaces de noms permettent d'organiser de maniere logique l'ensemble des objets de la librairie, 
le regroupement etant generalement realise par centres d'interet. Par exemple : 

namespace NomDeSociete.Projet //definit 1 'espace de noms du projet 
{ 
public class Console // NomDeSociete.Projet. Console 
{ 

// (...) 
} 

namespace MonSousEspace // definit un sous-espace de noms dans le projet 
{ 
public class MaClasseDansMonSousEspace 
{ 
public static void HelloO // methode HelloO 
{ 
// methode WriteLineO de la classe Console de 1 'espace System 
System. Console.WriteLineC'Hel lo") ; 
} 
} 
} // MonSousEspace 
} // NomDeSociete.Projet 

// Une classe isolee de tout espace de noms 

public class MaClasselsolee 

{ 

public static void MainO 

{ 
NomDeSociete. Pro jet.MonSous Espace. MaCl a sseDansMonSous Espace. Hel lot ) ; 

} 
) 

La convention utilisee pour nommer les espaces de noms et les classes s'appuie sur une syntaxe du 
type : [Namespace]+. <C1 ass>. Ce schema de noms permet d'etablir une hierarchie logique des espaces 
(une arborescence) qui offre encore plus de possibilites dans F organisation de la librairie. Par exem- 
ple : System. Web. Services. WebService identifie la classe WebService dans Fespace de noms 

System. Web. Services. 

Attention, cette organisation logique arborescente concerne les contextes de nommage et reste sans 
rapport avec la hierarchie des classes du modele objet ou avec la facon dont les classes sont imple- 
mentees dans les assemblages (un assemblage peut regrouper plusieurs espaces de noms, et inverse- 
ment, un espace de noms peut etre implemente dans plusieurs assemblages). Par exemple, la classe 
System. Web. Services. WebService herite de la classe System.ComponentModel .Marshal ByValueComponent. 
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II n'y a pas de relation objet avec une classe quelconque de l'espace System. Web mais il y a en 
revanche des centres d'interet communs puisque ce dernier espace regroupe les classes qui permet- 
tent de gerer la communication entre une navigateur Internet et un serveur (telle que la classe 
HttpRequest). 

En conclusion, les espaces de noms sont un mecanisme qui permet a la fois d'eviter les ambiguites de 
noms et d'organiser les objets de la librairie par centres d'interet. 



Recommandation 

Microsoft recommande que les espaces de noms crees dans le cadre des applications soient nommes de la 
maniere suivante : NomDeSoci ete . Technol ogi e. 

De maniere generale, Microsoft suggere en outre d'utiliser la notation Camel (les noms commencent par une 
minuscule) pour les variables (exemple : uneVariable) et la notation Pascal (les noms commencent par une 
majuscule) pour le reste (exemple : MaMethode) ; voir msdn.microsoft.com/library/en-us/cpgenref/html/cpconca- 
pitalizationstyles. asp. 



L'organisation de la librairie 

Nous venons de voir que la librairie objet etait organisee selon une hierarchie d' espaces de noms. Les 
principaux espaces de noms du framework .NET sont les suivants : 

• Microsoft.Csharp, qui contient les classes gerant la compilation et la generation de code en 
langage C# ; 

• Microsoft.JScript, qui contient les classes gerant la compilation et la generation de code en 
langage Jscript ; 

• Mi crosof t . Vi sual Basi c, qui contient les classes gerant la compilation et la generation de code en 
langage Visual Basic ; 

• Mi crosof t . Vsa, qui contient les interfaces permettant d'integrer dans des applications la prise en charge 
de Visual Studio pour Applications (VSA) pour le framework .NET (compilation et execution) ; 

• Microsoft. Win32, qui fournit les classes permettant de gerer les evenements declenches par le 
systeme d' exploitation, ainsi que les classes permettant de manipuler la base de registre ; 

• System, qui contient les classes fondamentales defrnissant les types de donnees, les evenements et 
les gestionnaires d' evenements, les interfaces, les attributs et les exceptions, etc. 

L'espace de noms System 

L'espace System contient la classe Object qui est la racine du modele objet, c'est-a-dire la classe dont 
toutes les autres heritent. Cette classe fournit quelques methodes fondamentales qui seront surchargees 
par les classes filles : 

• EqualsO, 

• GetTypeO, 

• ToStringO, etc. 
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L'espace System contient environ une centaine de classes. Parmi elles, on trouve celles qui definissent 
les types de donnees de base qui correspondent aux types de donnees primitifs des langages de 
programmation tels que Byte ou Int32, II est interessant de remarquer que le developpeur peut declarer 
une variable en utilisant : 

• soit le mot-cle du langage ; 

• soit le type de donnees du framework. 

Par exemple, declarer System. Int32 monEntier est strictement identique a int monEntier en C# (y 
compris en temps d'execution). 

Le tableau suivant montre la correspondance entre les types de base du framework et ceux de differents 
langages mis en ceuvre en .NET. 



Tableau de correspondance des types 



Categorie Nomde Description Type TypeC# Type C++ Type 
classe Visual (managed) JScript 

Basic 


Entier 


Byte 


Entier 8 bits non signe. 


Byte 


Byte 


Char 


byte 


SByte 


Entier 8 bits signe. 
Non compatible CLS. 


N/A. 


sbyte 


signed char 


SByte 


Intl6 


Entier 16 bits signe. 


Short 


short 


Short 


short 


Int32 


Entier 32 bits signe. 


Integer 


Int 


int 

-ou- 

long 


int 


Int64 


Entier 64 bits signe. 


Long 


Long 


_int64 


long 


UIntl6 


Entier 16 bits non signe. 
Non compatible CLS. 


N/A. 


ushort 


unsigned short 


UIntl6 


UInt32 


Entier 32 bits non signe. 
Non compatible CLS. 


N/A. 


Uint 


unsigned int 
-ou- 
unsigned long 


UInt32 


UInt64 


Entier 64 bits non signe. 
Non compatible CLS. 


N/A. 


ulong 


unsigned 
_int64 


UInt64 


Flottant 


Single 


Un nombre a virgule flottante 
simple precision (32 bits). 


Single 


float 


Float 


float 


Double 


Un nombre a virgule flottante 
double precision (64 bits). 


Double 


double 


Double 


double 


Logique 


Boolean 


Un booleen (vrai ou faux). 


Boolean 


Bool 


Bool 


bool 
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Tableau de correspondance des types (suite) 



Categorie Nom de Description Type Type C# Type C++ Type 
classe Visual (managed) JScript 

Basic 


Autre 


Char 


Un caractere Unicode (16 bits). 


Char 


Char 


wchar_t 


char 


Decimal 


Un decimal 96 bits. 


Decimal 


decimal 


Decimal 


Decimal 


IntPtr 


Un entier signe dont la taille depend 
de la plate-forme (32-bits sur une 
plate-forme 32-bits et 64-bits sur 
une plate-forme 64-bits). 


N/A. 


N/A. 


N/A. 


IntPtr 


UintPtr 


Un entier non signe dont la taille 
depend de la plate-forme (32 bits 
sur une plate-forme 32 bits et 
64 bits sur une plate-forme 64 bits). 
Non compatible CLS. 


N/A. 


N/A. 


N/A. 


UintPtr 


Classe 
objet 




Object 


La racine de la hierarchie objet. 


Object 


object 


Object* 


Object 


String 


Une chaine de caracteres Unicode 
de longueur fixe. 


String 


string 


String* 


String 



Remarque 

N/A signifie qu'il n'y a pas de type primitif correspondant. L'utilisation de la classe objet est obligatoire. 



L'espace System est a la base d'une arborescence d'espaces qui decrivent aussi bien des concepts 
fondamentaux de programmation tels que System. Col lections (gestion des collections, listes, 
queues, etc.) ou System. 10 (lecture et ecriture de fichiers, flux de donnees, etc.), que des services 
beaucoup plus complexes tels que System. Data (architecture de gestion des donnees ADO.NET) ou 
System. Drawing (fonctions graphiques de base GDI+). 

Le tableau ci-apres decrit les principaux espaces de noms organises sous System. 

Tableau des espaces de noms 



Categorie Espace de noms Description 


Modele de 
composant 


System. CodeDom 


Representation des elements et de la structure d'un document 
de code source ; compilation et manipulation du code en 
question. 


System. ComponentModel 


Implementation de composants y compris en mode design et 
gestion des licences. 


Configuration 


System. Configuration 


Recuperation des donnees de configuration de I'application. 


Donnees 


System. Data 


Acces et gestion des donnees et des sources de donnees, y 
compris ADO.NET. 


System. Xml 


Prise en charge des standards W3C XML (parser XML, transfor- 
mation XSLT, support Xpath, schemas, etc.). 


System. Xml .Serial izati on 


Serialisation d'objets en XML (bidirectionnelle). 
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Tableau des espaces de noms (suite) 



Categorie Espace de noms Description 


Services 
du framework 


System. Diagnostics 


Interaction avec les processus systeme, les journaux d'evene- 
ments et les compteurs de performance. 


System. Di rectory Services 


Acces a tous les fournisseurs Active Directory : IIS, LDAP, LDS 
etWinNT. 


System. Management 


Acces aux informations et aux evenements de gestion du sys- 
teme et des peripheriques. 


System. Messaging 


Acces a Microsoft Message Queuing (MSMQ). 


System.ServiceProcess 


Installation, implementation et controle de services Windows. 


System. Timers 


Horloge serveur (et non Windows). 


Globalisation 
et localisation 


System. Global ization 


Acces aux informations (parametres regionaux) permettant de 
gerer la localisation du code et des ressources. 


System. Resources 


Gestion de ressources. 


Reseau 


System. Net 


Interface de programmation des protocoles reseau courants 
(sockets, serveurs DNS, couches basses IP, etc.). 


Tronc commun 


System. Collections 


Collections variees d'objets, telles que listes, queues, tableaux, 
etc. 


System. 10 


Lecture et ecriture synchrone et asynchrone de flux de donnees 
et de fichiers. 


System. Text 


Encodage et conversion de caracteres, manipulation de chaines. 


Sy stem. Text. Reg ul a r Express ions 


Prise en charge des expressions regulieres. 


System. Threading 


Prise en charge de la programmation multithread et des primiti- 
ves de synchronisation. 


Reflection 


System. Reflection 


Acces aux metadonnees, creation dynamique et invocation de 
types. 


Interface 
graphique GUI 


System. Drawing 


Acces au GDI+ (graphisme 2-D). 


System. Windows . Forms 


Gestion d'interface utilisateur pour des applications Windows. 


Services 

d'infrastructure 

duCLR 


System .Runtime . Compi 1 erServi ces 


Prise en charge pour les compilateurs compatibles avec le CLR. 


System. Runtime. InteropServices 


Prise en charge d'interoperabilite avec COM, I'API Windows, etc. 


System . Runti me . Remoti ng 


Creation et configuration d'applications distributes (protocole 
binairesurTCPouSOAP). 


System. Runtime. Serial ization 


Serialisation et deserialisation d'objets, y compris encodage 
binaire et SOAP. 


Securite du 
framework .NET 
Services Web 


System. Security 


Acces au systeme de securite du CLR. 


System. Security. Cryptography 


Services de cryptographie, y compris encodage et decodage de 
donnees, hachage, generation de nombres aleatoires, signatu- 
res numeriques, etc. 


System. Web 


Conception et gestion de clients et de serveurs Web. Fournit 
I'infrastructure de base pour ASP.NET, y compris la prise en 
charge des Web Forms. 


System. Web. Services 


Prise en charge des services Web SOAP (client et serveur). 
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Les langages du framework et C# 

Le framework .NET est un environnement multilangage. Qui plus est, tous ces langages peuvent inter- 
operer entre eux, et permettent d'acceder a la librairie objet de maniere identique. Cette equivalence 
des langages vis-a-vis de la plate-forme est une grande premiere dans le monde du developpement 
informatique. 

Microsoft prend en charge d'emblee cinq langages : 

• Visual Basic.NET, un langage incontournable du fait de sa popularite. Cependant, cette nouvelle 
version secoue quelque peu la communaute des developpeurs car certains trouvent que le langage s'est 
trop complexifie, alors que d'autres sont satisfaits d' avoir enfin un veritable langage oriente objet ; 

• C++, grace auquel il est maintenant possible d'ecrire des programmes en managed code, c'est-a- 
dire geres par le CLR du framework ; 

• Jscript NET, le Jscript est maintenant compile ; 

• le nouveau langage C# ; 

• J#, un langage Java version Microsoft (dont la compatibilite avec l'API Java s'arrete a la 
version 1.1.4du JDK). 

Un certain nombre d'editeurs sont d'ores et deja references comme partenaires Microsoft au sein du 
programme Visual Studio.NET Integration program (voir http://msdn.microsoft.com/vstudio/partners/ 
language/default.asp) et proposent diverses implementations de langages. Cette liste permet d'avoir un 
apercu de l'etendue des langages pris en charge par le framework : 

• APL par Dyadic Systems (voir Dyalog APL/W v 9.0 a http://www.dyadic.com/) ; 

• COBOL par Fujitsu (voir NetCOBOL a http://www.netcobol.com/) ; 

• EIFFEL par Interactive Software (voir Eiffel# a http://dotnet.eiffel.com) qui propose aussi son propre 
IDE de developpement EiffelStudio ; 

• FORTH par DataMan ; 

• FORTRAN par Fujitsu/Lahey (voir http://www.lahey.com) ou Salford (voir FTN95 for .NET a http:// 
www.salfordsoftware.co.uk) ; 

• MERCURY par l'universite de Melbourne en Australie (voir http://www.cs.mu.oz.au/mercury) ; 

• MONDRIAN (et HASKELL) par l'universite de Massey en Nouvelle-Zelande (voir http://mondrian- 
script.com) ; 

• OBERON par ETH Zentrum (voir http://www.oberon.ethz.ch) ; 

• PASCAL par l'universite de Queensland en Australie (voir http://www.fit.qut.edu.au/plas/component- 
Pascal) ou TMT Development (voir http://www.tmt.com) ; 

• PERL par ActiveState (voir Visual Perl a http://activestate.com/products/visual_perl) ; 

• PYTHON par ActiveState (voir Visual Python a http://activestate.com/products/visualjjython) ; 

• RPG par ASNA (voir ACR for .NET a http://www.asna.com/avr_caviar_information.com) ; 

• SCHEME par l'universite de Northwestern aux Etats-Unis (voir Hotdog a http://rover.cs.nwu.edu/ 
-scheme) ; 

• SMALLSCRIPT (dialect Smalltalk-98) par SmallScript Corp. (voir http://www.smallscript.net). 



La plate-forme .NET 

Chapitre 15 

Le choix d'un de ces langages depend des choix et des habitudes de developpement. Dans cette panoplie, 
deux gagnent rapidement en popularite : 

• Visual Basic.NET, qui va heriter de la popularite de Visual Basic ; 

• C#, particulierement pousse par Microsoft, qui a beaucoup investi sur le sujet (toute la librairie 
objet a ete ecrite en C#). 

Le langage C# est suffisamment proche de C++ et Java pour que beaucoup de developpeurs se 
l'approprient sans trop de difficulte. 

Cette proximite mise a part, le langage C# a beaucoup de qualites intrinseques : c'est un veritable 
langage objet, simple, precis et productif. Ses qualites, il les tire a la fois de C++ mais aussi des huit 
annees d'experience Java. Le resultat est done un condense du meilleur des deux mondes. 

Pour garantir un peu plus son succes, le langage C# a ete depose conjointement par Microsoft, 
Hewlett Packard et Intel a l'ECMA. Le langage est done maintenant un standard (au meme titre que 
JavaScript) enregistre depuis decembre 2001 sous la reference ECMA-334. 

Les traits du langage C# 

Notre objectif n'est pas de decrire en detail le langage C#, mais simplement de faire remarquer que, 
meme si les langages compatibles avec le framework .NET ont un niveau fonctionnel assez equiva- 
lent, il subsiste des differences plus ou moins importantes entre eux. C'est le cas du langage C# qui 
presente certains traits particuliers : 

• la surcharge d'operateurs permet de redefinir des operateurs pour de nouveaux types definis (existe 
aussi en C++) ; 

• les proprietes indexees ou indexeurs permettent de creer des classes qui agissent comme des 
« tableaux virtuels » a Faide de l'operateur [] : 

String s = monInstance[3] ; 

public Class monlnstance { 
public String thi s [ Int i] ( 
get{ // retourne la chaine en position i} 
set{ // affecte a la valeur en position i} 
} 
} 

le boxing et le unboxing permettent respectivement de convertir un type primitif en un objet et 
inversement (syntaxe du cast) : 

int valeur = 123; 

object o = valeur; // boxing int en objet 

int valeur2 = (int) o; // unboxing 

la generation automatique de documentation XML a Faide de la suite de caracteres « /// » ; 

la possibility d'integrer des extensions C++ de code unmanaged (usage de pointeurs par exemple). 
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ASP.NET 



ASP.NET est la nouvelle version d' Active Server Pages (ASP) et fait partie integrante du framework 
.NET (voir figure 15-2) . Comme nous allons le voir, cette technologie serveur qui permet de creer 
des applications Internet dynamiques et des services Web a enormement evolue. 

Une evolution necessaire d'ASP 

Le fonctionnement de la precedente version d'ASP etait relativement simple : les pages ASP etaient 
des pages HTML qui contenaient des scripts (Jscript ou VBScript). En reponse a une requete HTTP, 
le code de ces pages etait interprets par un service IIS et la page HTML resultante envoyee au navi- 
gateur client. Ces scripts pouvaient faire appel a des composants COM pour acceder a des sources de 
donnees (ADO), a des donnees XML (MSXML), ou a tout composant metier. 

Les changements introduits dans ASP.NET par rapport a la precedente version sont majeurs et 
personne ne s'en plaindra vraiment, car le modele ASP 3.0 souffrait de nombreuses lacunes : 

• les langages de script (VBScript ou Jscript) etaient dynamiquement types, peu structures et interpreted ; 

• les pages melangeaient le HTML et le code de script, ce qui ne facilitait pas leur lisibilite et leur 
maintenance (« code spaghetti ») ; 

• la separation claire des trois niveaux de traitement (presentation, code metier, donnees) etait diffi- 
cilement maintenable et peu utilisee dans les faits ; 

• l'environnement de developpement et de mise au point etait archaique et peu puissant. 

Certes, la simplicite de cette technologie et sa rapidite de mise en ceuvre ont contribue dans un 
premier temps a son succes. Mais, face a des concurrents comme PHP ou JSP, cette technologie avait 
besoin d'evoluer, d'autant plus que le developpement d' applications Internet dynamiques est devenu 
un imperatif incontournable. 

Presentation generale d'ASP.NET 

ASP.NET est done la nouvelle plate-forme unifiee de developpement que propose Microsoft pour 
construire tout type d' application serveur orientee Internet. Cette infrastructure offre aux deve- 
loppeurs deux fonctionnalites principales qui peuvent etre combinees entre elles : 

• les Web Forms, 

• les services Web XML. 

Dans les deux cas, les moyens mis en ceuvre sont les memes et les evolutions par rapport a la prece- 
dente version d'ASP sont majeures. 

Le fonctionnement d'ASP.NET 

Nous allons commencer par expliquer brievement comment fonctionne une application ASP.NET 

Le CLR a ete concu pour prendre en charge differents scenarios d' applications : depuis une applica- 
tion serveur Internet jusqu'a une application Windows en passant par une application console. 
Chaque type d'application necessite unprogramme hote specifique qui doit s'occuper de : 

1. charger le CLR dans un processus ; 

2. creer un domaine d'application dans ce processus ; 

3. charger le code utilisateur dans ce domaine. 
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Debug 

Services du systeme d'exploitation 
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Figure 15-5 

Architecture d 'ASP.NET. 

ASP.NET, tout comme Internet Explorer et le shell de Windows, est Fun de ces programmes notes 
fournis par le framework .NET : son role consiste done a charger le CLR dans le processus qui doit 
traiter la requete Internet puis a creer un domaine d'application pour chaque application Internet qui 
tourne sur le serveur. 



Developpement de programmes notes 

Le SDK du framework .NET fournit une API de developpement de programmes hotes. 



Une application .NET 

ASP.NET peut heberger des programmes ecrits avec n'importe quel langage .NET (Visual 
Basic.NET, Jscript.NET, C#, etc.) puisqu'un programme ASP.NET est traite par le CLR comme toute 
application ecrite pour le framework. 

Bien evidemment, les developpeurs ont acces a l'ensemble de la librairie objet du framework, ce qui 
leur permet de beneficier de sa richesse intrinseque, et ils peuvent egalement beneficier des develop- 
pements specifiques qu'ils ont pu eux-memes realiser. 

Un environnement oriente objet 

La plate forme ASP.NET est totalement orientee objet et toutes les classes s'inscrivent dans la librai- 
rie objet du framework. Une page ASP.NET (extension .aspx) ou celle d'un service Web XML 
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(extension .asmx) sont bien des instances de classes qui possedent des methodes, des proprietes et 
meme des evenements, comme nous le verrons plus loin. 

Une architecture n-tiers 

Au-dela de la programmation orientee objet, les applications ASP.NET s'inscrivent dans une archi- 
tecture qui permet de bien separer les niveaux : le code de presentation (HTML) est bien separe du 
code metier (voir la section « Les Web Forms »), lui-meme separe de la couche de donnees. 

Lacces aux donnees est realise parADO.NET (espace de noms System. Data) qui permet de gerer des 
sources de donnees variees telles que SQL Server, OLE DB et XML. Ce modele de donnees a ete 
specialement concu pour les applications orientees Internet en fournissant une architecture faible- 
ment couplee et en s'appuyant systematiquement sur les standards XML. Ainsi, ADO.NET fournit 
une classe DataSet qui permet de manipuler des donnees issues d'origines diverses et deconnectees 
de leurs sources (mecanisme de synchronisation evolue). Le conteneur de donnees resultant peut etre 
lu ou enregistre au format XML. II permet en outre d'appliquer des regies d'integrite, de gerer des 
relations et des hierarchies, F ensemble etant decrit par un schema XML. 



ADO et ADO.NET 

ADO.NET est une evolution d'ADO mais certaines fonctionnalites ne sont par fournies par ADO.NET, comme les 
curseurs serveur. ADO peut toujours etre utilise par une application .NET, comme tout composant COM. 



Des gains de performance 

Les gains de performance d' ASP.NET par rapport a ses predecesseurs sont tres importants, d'abord 
parce que les programmes sont compiles et ensuite parce qu' ASP.NET dispose de fonctions evoluees 
de gestion de cache : 

• au niveau des pages elles-memes, par Futilisation d'une directive ©OutputCache (placee dans l'en- 
tete de la page) ou de la classe HttpCachePol 1 cy (implementee par la propriete HttpResponse . Cache 
et done accessible depuis Page. Response) ; 

• au niveau des donnees manipulees par les programmes, via l'utilisation de la classe Cache de 
l'espace denoms System. Web. Caching. 

La configuration des applications 

L infrastructure de configuration des applications ASP.NET est a la fois simple et efficace, et s'appa- 
rente d'une certaine maniere aux principes utilises dans le monde Unix. Elle est simple car elle est 
realisee a partir d'un ensemble de fichiers XML bien formes, facilement comprehensibles, et modi- 
fiables manuellement avec tout editeur. Cette infrastructure n'en est pas moins efficace puisque : 

• Elle prend en charge de tres nombreux parametres, depuis la gestion des sessions jusqu'a la securite, 
en passant par la gestion des traces. 

• Elle permet la prise en charge des parametres specifiques de 1' application (accessibles depuis une 
collection statique ConfigurationSettings.AppSettings) comme : 

I<!- fichier web.config. --> 
<configuration> 
<appSettings> 
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<add key="Titre" value="Mon application" /> 
</appSettings> 
</configuration> 

// code C# 

String title - ConfigurationSettings.AppSettings["Titre"] ; 

Elle peut etre etendue pour repondre a des besoins specifiques en creant de nouvelles sections dans 
les fichiers de configuration. Ce mecanisme est utilise par le framework lui-meme dans le fichier 
machine.config pour definir les sections des fichiers de configuration web. config. 

Elle permet de modifier une grande partie des parametres de F application sans recompilation ni 
redemarrage du serveur IIS (ASP.NET detecte automatiquement les changements et remet imme- 
diatement les nouveaux parametres en cache) ; ces modifications peuvent pourtant etre aussi 
importantes que le changement du mode de gestion des etats de session (voir la section « La 
gestion d'etats »). 

Elle est securisee, puisque les fichiers de configuration sont proteges par IIS et inaccessibles depuis 
un navigateur. 



Formalisme 

Les fichiers de configuration sont des fichiers XML bien formes et sensibles a la casse des caracteres. II est recom- 
mande d'utiliser la notation Camel pour les balises et les attributs et la notation Pascal pour les valeurs d'attributs. 



Les fichiers de configuration sont organises de maniere hierarchique. Cette hierarchie determine 
l'ordre dans lequel les parametres sont pris en compte par le framework a 1' execution de chaque 
application. II existe trois types de fichiers de configuration : 

• Machi ne . conf i g : il s'agit du fichier de configuration du framework.NET. II est valable pour toutes 
les applications hebergees par la machine et contient les parametres du CLR, du systeme de remo- 
ting et d' ASP.NET. 

• Les fichiers de configuration de la securite (Enterprisesec. config et Security. config), assez 
complexes, pour lesquels il est recommande d'utiliser des utilitaires specifiques : l'outil de confi- 
guration du framework .NET (Mscorcfg.msc) et l'outil de gestion de la politique de securite 
(Caspol . exe). Ces fichiers traitent egalement le parametrage global. 

• Les fichiers de configuration d' application. II existe typiquement un fichier par application .NET et 
pour les applications ASP.NET, il s'agit d'un fichier Web. config situe a la racine du repertoire 
virtuel. 

Les fichiers devant agir au plus haut de la hierarchie de parametrage doivent etre enregistres dans le 
repertoire d' installation du run-time .NET (exemple : C:\WINNT\Microsoft.NET\Framework\ 
vl.0.3705\C0NFIG). C est done en particulier le cas du fichier Machine.config. 

Dans un premier temps, le developpement d'un nouveau projetASP.NET ne necessite la modification 
que du fichier de configuration de l'application Web. config. La modification des autres fichiers 
n'intervient que dans le cadre d'un parametrage plus complexe (valable par exemple pour un ensemble 
de sites Internet) ou la definition globale de la securite sur la machine. 
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Mais cette notion de hierarchie intervient encore ail niveau des fichiers de parametrage de 1' applica- 
tion puisqu'il est possible de definir pour une application ASP.NET plusieurs fichiers Web.config 
enregistres dans differents repertoires de F application : ces fichiers permettent de definir un parame- 
trage specifique valable pour les ressources situees dans ce meme repertoire et dans ses sous-repertoires. 
Par exemple, un site Internet disposant d'un espace public et d'un espace prive soumis a une authen- 
tification peut disposer de deux fichiers Web . conf i g. La hierarchie entre ces differents fichiers permet 
a chaque niveau d'heriter des parametres du niveau superieur. Cette hierarchie est determinee par 
ASP.NET en fonction de l'URL utilisee pour acceder a une ressource. 



Repertoires virtuels et repertoires physiques 

II est done recommande de creer une structure de repertoires virtuels qui soit coherente avec celle des repertoires 
physiques. Sinon, il peut etre difficile pour un developpeur de maitriser la hierarchie des fichiers de configuration. 



Ce parametrage specifique des ressources peut egalement etre realise a partir d'un seul fichier 
Web. Conf ig a Faide d'une balise specifique <location>. Exemple : 

<configuration> 

<!- Configuration generale. --> 
<system.web> 
Authentication mode="Forms" > 
<forms name="monSiteAUTH" 
loginUrl="/logon.aspx" 
protection="Al 1 " 
timeout="30" 
path=V" /> 
</authentification> 
</system.web> 

<!- Configuration specifique du repertoire "Repl". --> 
<location path="Repl"> 
<system.web> 

<authentication mode="None" /> 
</system.web> 
</location> 
</configuration> 

La gestion d'etats 

La gestion d'etats est un mecanisme qui consiste a maintenir des informations pour une page en parti- 
culier, ou pour les pages visitees par un client, tout au long d'une sequence de requetes HTTP. II 
existe deux options pour sauvegarder ces informations : 

• au niveau du client avec les techniques classiques qui consistent a utiliser des champs caches, des 
cookies ou des query strings ; 

• au niveau du serveur avec la gestion d'etats d' application, la gestion d'etats de session ou 1' usage 
de bases de donnees. 
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La gestion d'etats au niveau du client 



En ce qui concerne la gestion d'etats au niveau du client, ASP.NET fournit un mecanisme interessant 
appele View State qui facilite l'usage des champs caches. Ce mecanisme est d'abord utilise par le 
framework lui-meme pour maintenir automatiquement les proprietes d'une page et les valeurs de ses 
champs lorsqu'un formulaire effectue des allers-retours client-serveur (round-trip). Mais il peut 
egalement etre utilise par les developpeurs pour sauvegarder volontairement des donnees. 

Ce mecanisme est mis en ceuvre grace a un dictionnaire (classe StateBag) expose par la propriete 
ViewState de la classe Control (namespace System. Web. UI). II est done disponible pour chaque 
controle d'une page ainsi que pour la page elle-meme. A 1' execution, le framework se charge automa- 
tiquement de transformer chaque dictionnaire en cles hachees sauvegardees dans des controles 
caches et inversement. Exemple : 

III code C# dans une page 
ViewState["Couleur"] = "rouge"; 

La gestion d'etats de session 

Dans le cadre des applications Internet, la gestion d'etats de session est une fonction tres importante 
car elle est souvent incontournable (par exemple, pour gerer un panier de commande). ASP.NET 
fournit un mecanisme assez evolue pour cette gestion et sa mise en ceuvre. 

Rappelons tout d'abord qu'une session est definie comme etant la periode de temps durant laquelle 
un client interagit avec une application Internet (il y a done une session par client). La gestion d'etats 
de session consiste simplement a pouvoir gerer et maintenir sur le serveur des informations pour 
chaque session. Ces donnees sont sauvegardees dans un dictionnaire expose par la classe HttpSes- 
sionState (espace de noms System. Web. SessionState). Cette classe est par exemple accessible depuis 
une propriete Session de l'objet Page : 

III code C# dans une page ou Global. asax. 
Session["DateDebut"] - DateTime.Now; 

ASP.NET prend en charge trois modes de gestion des donnees de session : 

• Le mode In-Process est le plus classique et le plus simple puisque les donnees de session sont 
gerees dans le meme processus que FapplicationASP.NET. Ce traitement est performant et adapte 
pour des applications non critiques fonctionnant sur un serveur unique. 

• Le mode Out-of-process est plus complexe puisqu'il consiste a gerer les donnees de session dans 
un processus independant. Cette mise en ceuvre est realisee grace a un service Windows ASPState 
fourni avec le SDK du framework .NET. Ce service peut evidemment etre deporte sur un serveur 
independant pour centraliser la gestion des sessions d'une ferme de serveurs Internet. 

• Le mode SQL Server est assez equivalent au precedent mis a part que les donnees ne sont pas 
gerees en memoire mais par Microsoft SQL Server. Un script Instal 1 Sql State . sql est fourni avec 
le SDK du framework .NET qui permet de configurer le SGBD pour cette tache en creant les tables 
et les procedures stockees necessaires dans la base ASPState. Ce mode de gestion offre un niveau 
de disponibilite maximal, d'autant plus que SQL Server peut lui-meme etre configure en cluster. 
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Le choix du mode de gestion est realise par le biais du flchier de configuration XML web . conf i g (ou 
machi ne . conf i g ) de 1' application. Non seulement ce parametrage est simple mais il peut etre modifie 
a tout instant sans qu'il soit necessaire d'intervenir sur le code source de l'application. 

Exemple de configuration Out-of-process : 

<configuration> 
<system.web> 
<sessionstate mode="stateserver" 
timeout="20" 

stateconnectionstring= "tcpip=137. 0.0.1 :42424" /> 
</system.web> 
</configuration> 

Exemple de configuration SQL Server : 

<configuration> 
<system.web> 
<sessionstate mode="sql server" 
timeout="20" 

sqlconnectionstring="data source=MaDataSource; 
user id=MonId; 
password=MonPwd" /> 
</system.web> 
</configuration> 

Enfin, ASP.NET prend en charge la gestion de sessions meme lorsque les clients n'acceptent pas les 
cookies. Ce mecanisme est assez complexe puisqu'il consiste a integrer dans toutes les URL l'identifi- 
cation de la session. Et pourtant, il suffit de modifier le fichier de configuration pour le mettre en ceuvre : 

<configuration> 
<system.web> 
<sessionState mode="Inproc" 
cookieless="true" 
timeout="20" /> 
</sessionState> 
</system.web> 
</configuration> 

La gestion d'etat d'application 

La gestion d'etat d'application equivaut a gerer des variables globales. Elle doit cependant etre utili- 
see avec precaution car elle necessite un mecanisme complexe de synchronisation des acces concurrents 
et ne fonctionne pas dans un environnement multiserveur ou multiprocessus. 

La gestion des donnees est realisee avec un dictionnaire expose par la classe HttpApplicationState 
(espace de noms System . Web). Cette classe est par exemple accessible depuis une propriete Appl 1 cati on 
de l'objet Page : 

// code C# dans une page ou Global. asax. 
Appl i cati on. Lock( ) ; 

Appl ication["DateDebut"] = DateTime.Now; 
Appl ication.UnLockt ) ; 



La plate-forme .NET 

Chapitre 15 

La securite 

La gestion de la securite est une fonction essentielle dans le developpement des applications informa- 
tiques en general, et Internet en particulier. Cette gestion est mise en ceuvre par un ensemble de 
moyens qui se situent a differents niveaux de F architecture : 

• IIS (en collaboration avec le systeme d' exploitation Windows), 

• ASP.NET, 

• le framework .NET (CLR), 

• le systeme d' exploitation Windows (NTFS). 

Evidemment, il n'est pas question ici de dresser un tableau exhaustif de ces moyens mais plutot de 
decrire rapidement les possibilites offertes pour gerer les trois fonctions fondamentales que sont : 

• la fonction d' authentication, 

• la fonction d'autorisation, 

• et la fonction d'endossement de personnalite. 

Les applications ASP.NET etant des applications .NET a pail entiere, il est egalement possible de 
tirer partie de toutes les fonctions de gestion de la securite prises en charge par le framework (voir la 
section « La gestion de la securite »). 

L'authentification 

Le processus d'authentification consiste a obtenir les elements d' identification d'un utilisateur, tel 
qu'un login et un mot de passe, et de valider ces elements aupres d'une autorite : si ces elements sont 
valides, Futilisateur est considere comme authentifie. 

L'authentification peut etre realisee de trois facons par une application ASP.NET : 

• Forms : ce mode permet a 1' application d'effectuer elle-meme le controle de validite des elements 
d'authentification depuis un fichier de configuration, une base de donnees ou ADSI (API de 
Fannuaire Active Directory). Ce controle se traduit par remission d'un cookie d'authentification 
qui valide les requetes suivantes. Les requetes non validees sont redirigees automatiquement vers 
une page de logon. 

• Microsoft Passport : il s'agit d'un service centralise d'authentification fourni par Microsoft. II 
s'appuie sur une mecanique de type Forms, le protocole SSL et un triple encryptage DES des cles. 
Un SDK specifique doit etre installe, disponible a http://www.microsoft.com/net/services/passport/. 

• Windows : il s'agit du mode d'authentification classique d'HS (basic, digest ou Windows). 

Dans les trois cas, un evenement OnAuthenticate est declenche dans le fichier global .asax et permet 
au developpeur d'implementer son propre schema de securite en modifiant les objets Windowslden- 
tity (Futilisateur) et WindowsPrincipal (le groupe) au moment de leur creation. 

II est important de comprendre que le mode Forms ne peut proteger que les ressources specifiques a 
ASP.NET, c'est-a-dire les pages .aspx, .asmx, etc. Les requetes qui concernent des ressources Gif, 
Jpeg ou Html ne sont pas traitees par le serveur ISAPI ASP.NET et ne sont done pas soumises a une 
demande d'authentification. Seul le mode Windows d'HS permet de traiter Fensemble des requetes et 
done toutes les ressources. 
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Le mode Forms necessite plus de developpement que le mode Windows qui necessite peu de code 
voire pas du tout. Neanmoins, ce developpement est facilite par les methodes statiques que fournit la 
classe FormsAuthentification (espace de noms System. Web. Security) et peut par exemple se limiter 
a la page de logon suivante : 

<%@ Page LANGUAGE="C#" %> 
<html> 
<head> 

<script language="C#" runat=server> 
void SubmitBtn_Cl ick(Object Source, EventArgs E) 
{ 
// verifie 1 'util isateur par rapport au fichier web.config. 
if ( Forms Aut henticati on. Authenticate (UserName. Value, User Pwd. Value) ) 
{ 
// redirection sur l'URL initiale et emission du cookie 
Forms Aut henti cation. Redi rectFromLogin Page (UserName. Value, false) ; 



Msg.Txt="Util isateur inconnu !"; 
) 
</script> 
</head> 

<body> 

<form method=post runat=server> 
<table> 
<tr> 

<td>Name:</td> 

<td><input type="text" id="UserName" runat=server/> 
</tr> 
<tr> 

<td>Password:</td> 

<td><input type="password" id="UserPwd" runat=server/X/td> 
</table> 
<br> 

<input type="submit" OnServerCl ick="SubmitBtn_Cl i ck" runat^server /> 
<asp:Label id="Msg" ForeColor="red" Font-Name="Verdana" Font-Size="10" runat=server /> 
</form> 
</body> 
</html> 

Une fois de plus, le choix du mode d'authentification est realise de maniere simple et rapide dans le 
fichier de configuration (web.config ou machine. config) : 

<system.web> 

<!-- mode=[windows [ Forms | Passport | None] --> 

Authentication mode="None" /> 
</system.web> 
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Le fichier de configuration est d'ailleurs largement utilise pour parameter le mode Forms : il permet 
de specifier la page de logon, les parametres utilises pour la generation et la validation du cookie et, 
en option, peut contenir la liste des utilisateurs habilites (les mots de passe ne sont pas stockes en 
clair). Exemple : 

<system.web> 
Authentication mode="Forms" > 
<forms name="monSiteAUTH" 
loginUrl="/logon.aspx" 
protection="Al 1 " 
timeout="30" 
path=V > 
<credential s pas sword Forma t="MD5"> 

<user name="Kim" password="9611E4F94EC4972D5A537EA28C69F89AD28E5B36"/> 
<user name="Tom" password="BA7157A99DFE9DD70A94D89844A4B4993B10168F"/> 
/credentials> 
</forms> 
</authentification> 
</system.web> 

L'autorisation 

Le processus d'autorisation consiste a verifier que Futilisateur identifie est autorise a acceder a une 
ressource. Cette verification est effectuee a deux niveaux : 

• la verification du fichier (FileAuthorizationModule) n'est active que lorsque le mode d'authentifi- 
cation utilise est le mode Windows, il s'agit d'une verification classique des droits NTFS ; 

• la verification URL (URLAuthori zati onModul e) est active des que le fichier de configuration web . conf i g 
contient une section <authorisation>. 

La gestion des autorisations au niveau du fichier de configuration permet d'autoriser ou de refuser a 
des utilisateurs et/ou a des groupes l'acces complet ou partiel (en specifiant un verbe HTTP : GET/ 
HEAD/POST/DEBUG) a des ressources. La hierarchie des fichiers de configuration ou la section <loca- 
tion> permet d'adapter les autorisations aux ressources d'une application ASP.NET (voir la section 
« La configuration des applications »). Exemple : 

<authorization> 

<! — Autorise le groupe Admin et 1 'util isateur John --> 

<allow roles="Admin"/> 

<allow users="monDomaine\John" /> 
<! — Interdit les utilisateurs anonymes --> 

<deny users="?" /> 
</authorization> 

L'endossement de personnalite 

Cette fonction permet d'executer l'application ASP.NET en utilisant l'identite de Futilisateur authen- 
tifie (y compris pour un utilisateur anonyme), quelle que soit la methode d'authentification utilisee. 
Typiquement, il s'agit de laisser a IIS la gestion de l'authentification, et d'appliquer la gestion des 
droits NTFS de Windows lors de 1' execution de l'application ASP.NET. Cependant, il est egalement 
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possible d'utiliser cette fonction pour forcer systematiquement l'identite de l'utilisateur qui execute 
1' application. 

Cette fonction doit etre activee (elle ne Test pas par defaut) par le biais du fichier de configuration. 
Exemple : 

i<system.web> 
<identity impersonate="true" userName="monDomaine\Franck" password="sesame" /> 
</system.web> 

Des fonctions de mise au point evoluees 

Une fonction de diagnostic est fournie et permet d'afficher des informations completes de trace et 
d'integrer du code de mise au point dans les programmes. Elle peut etre activee a la demande : 

• au niveau de chaque page grace a Fattribut Trace de la directive de page ©Page ; 

• ou au niveau de l'application a partir du fichier de configuration web . conf i g grace a l'attribut debug 
de la section <compi 1 ati on>. 

Le developpeur a la possibility d'enrichir le journal de diagnostic en incorporant ses propres messa- 
ges grace a l'objet Trace (disponible comme les objets Request, Response ou Context) ou a l'objet 
TraceContext (disponible a partir de la propriete Page. Trace ou Control .Context). Ce code n'a pas 
besoin d'etre supprime lors de la mise en exploitation de l'application. Toutes les informations de 
diagnostic sont organisees par tables et affichees a la fin des pages renvoyees au client ou optionnel- 
lement grace a un outil specifique de visualisation de Windows (trace . axd). 

A un autre niveau, les compteurs de performance de l'objet ASP.NET System, disponibles dans l'outil 
de monitoring systeme (PerfMon), sont dorenavant valables pour chaque application et non plus 
simplement de maniere globale pour un serveur IIS. Ces compteurs sont egalement accessibles 
depuis les applications elles-memes grace au composant PerformanceCounter (de l'espace de noms 
System. Diagnostics) pour permettre de les modifier ou de les lire. 

Les Web Forms 

Une fonction tres importante d' ASP.NET est de permettre d'associer un traitement serveur (un 
programme) a des pages qui sont envoyees a un navigateur Internet ou a tout autre peripherique sur le 
Web. Le developpement de sites Web dynamiques n'est pas simple car il necessite une bonne 
comprehension de la separation des roles entre le client et le serveur, la maitrise de techniques diver- 
ses inherentes au client, au serveur, aux protocoles, etc. ASP.NET ne dispense pas les developpeurs 
d'une bonne connaissance de ces techniques et de ces specificites mais il offre avec les Web Forms 
une couche d' abstraction qui permet de simplifier les developpements et a terme de gagner en 
productivite et en efficacite. Ces gains sont en particulier possibles parce que les Web Forms permet- 
tent d'utiliser des techniques de RAD (Rapid Application Development) bien connues des deve- 
loppeurs Visual Basic et mises en ceuvre par Visual Studio.NET Meme s'il est possible de develop- 
per des Web Forms sans cet outil, cela manque singulierement de sens vu les performances de 
developpement offertes par TIDE de Microsoft. 
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Une instance de Page 

De facon basique, pour creer une Web Form, il suffit simplement de remplacer, pour une page 
HTML, l'extension du fichier par ASPX et de placer le fichier dans un repertoire virtuel d'HS. Cette 
simple manipulation change pourtant radicalement la maniere dont va etre traitee cette page car elle 
est maintenant devenue un programme. La premiere fois qu'elle est consultee, ASP.NET : 

• genere automatiquement un programme qui implemente une classe heritant de System. Web. UI. Page 
(ce programme a evidemment comme tache premiere de generer le contenu HTML de la page) ; 

• compile cette classe et place F executable dans un repertoire specifique ; 

• execute le programme pour generer une occurrence de la page et le code HTML resultant. 

Notons que seule la derniere etape est effectuee pour les requetes suivantes : le programme est place 
dans un cache, ce qui permet d'ameliorer nettement les performances de F application. 

En resume, les Web Forms sont done des instances d'objets derivant de la classe Page. 

II est possible de poursuivre cet exemple et d'introduire directement dans la page ASPX du code 
source C# ou VB.NET qui sera execute sur le serveur. Exemple : 

<%@ Page Language="C#" l> 
<html> 

<body> 

<% for (int i=0; i<3; i++) { %> 

<tr><td>a=i3;></td></tr> 

<% } %> 

</body> 
</html> 

On reconnait la syntaxe qui etait utilisee par ASP a la fois au niveau de la directive de page 
(<@Page >) et des tags specifiques (<% %>) qui permettent d'introduire du code de rendu dans les 
pages. Le fait de pouvoir integrer des programmes directement dans les pages est done toujours 
d'actualite et ce precede est tout a fait acceptable dans la mesure ou le code concerne des 
elements de presentation. 

Pourtant, il est de bon usage de ne pas melanger la presentation avec le reste des programmes qui 
implementent la logique de F application. ASP.NET permet cette separation : 

• les elements visuels sont contenus dans le fichier ASPX (par exemple : WebForml . aspx) ; 

• les programmes sont deportes dans un fichier independant appele code behind (par exemple : 
WebForml.aspx.es en C#). 



Visual Studio.NET et WebMatrix 

WebMatrix est un IDE leger permettant de developper des applications ASP.Net. II est distribue gratuitement par 
Microsoft (http://www.microsoft.com/france/msdn/info/info^sp?mar=/france/msdn/technologies/technos/asp/info/ 
2002 1 706_aspnet-webmatrix. html) . 

Par defaut, Visual Studio.NET travaille toujours avec deux fichiers (ASPX + code behind). Les fonctions RAD ne 
sont disponibles que dans cette configuration. En revanche, WebMatrix ne travaille qu'avec des fichiers ASPX, d'ou 
un probleme de compatibilite, sans doute volontaire, entre les deux IDE. 
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Ces deux fichiers ne forment qu'une seule et meme entite qui est la page elle-meme. Cette interde- 
pendance est d'autant plus visible quand on s'interesse de nouveau au modele d'execution et au 
modele objet (voir figure 15-6) : 

• Le fichier code behind (WebForml.aspx.es) herite de System. Web. UI .Page. II implemente une 
classe utilisateur (WebForml) au sein d'un espace de noms de l'application (WebAppl icationl). 

• A la fin du developpement, le programme est compile dans une DLL (WebAppl 1 cati onl . dl 1 ). 

• Lors de la premiere consultation de la page, ASP.NET genere une nouvelle classe dans l'espace de 
noms ASP (WebForml_aspx) qui va generer le contenu de la page. Cette classe herite de la classe 
code behind implementee dans le programme compile. 

• ASP.NET compile cette classe de page et place l'executable (tempo ra ry . dl 1 ) dans un repertoire specifique. 

• Ce programme C# demeure dans le repertoire temporaire tant que ses dependances ne sont pas 
modifiees (fichier ASPX, code behind, etc.). II est execute a chaque requete HTTP pour instancier 
la page et generer le code HTML resultant. 
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Figure 15-6 

Le fonctionnement des Web Forms en developpement et a V execution. 
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Description generale 

Les elements d'interface qui composent une Web Form sont de deux types : 

• du texte litteral composes d'elements statiques en HTML, CSS, ECMAScript, etc. ; 

• des controles serveur. 

Le concept de controle d'interface n'est pas nouveau puisqu'il est largement utilise par les outils de RAD 
et en particulier Visual Basic, mais il n'est pas repandu dans le monde Internet. L'objectifd' ASP.NET est 
d'introduire une couche d' abstraction pour faciliter et accelerer le developpement des interfaces : 

• par la prise en charge de multiples navigateurs a partir d'une generation automatique de code 
HTML adapte ; 

• par la simplification de la gestion des echanges client-serveur a partir d'un modele evenementiel ; 

• par l'utilisation d'un modele objet complet qui facilite la manipulation des elements d'interface, 
Faeces au contexte HTTP, etc. 

La prise en charge multinavigateur 

Les controles utilises par les pages sont dits serveur car ils sont uniquement executes sur le serveur. 
Le resultat de cette execution et du traitement global des Web Form sont des pages HTML standards 
envoyees au client. L'objectif est de prendre en charge tous les navigateurs sur toutes les plates- 
formes. Pour ce faire, ASP.NET determine quel navigateur est utilise par l'utilisateur qui a emis la 
requete, et le classe selon deux niveaux : 

• le niveau avance (UpLevel) pour les navigateurs qui prennent en charge : 

- ECMAScript (JScript et JavaScript) 1.2, 

- HTML 4.0, 

- Microsoft Document Object Model (MSDOM), 

- les feuilles de style (CSS) ; 

• le niveau restreint (DownLevel) pour les autres navigateurs, qui correspond a un mode HTML 3.2. 

Le resultat de cette detection est decrit par l'objet System. Web. HttpBrowserCapabilities (accessible 
depuis Request . Browser). En fonction du niveau du navigateur, le code HTML genere par les contro- 
les differe (voir la section « Les controles de navigation »). 

Cette fonctionnalite est fort appreciable lorsque Ton connait les difficultes inherentes au developpe- 
ment d'un site Web grand public lie a la prise en charge d'une multitude de combinaisons version 
navigateur/plate-forme. 

Le modele evenementiel 

La programmation de l'interface s'appuie sur un modele evenementiel beaucoup plus intuitif et effi- 
cace qu'une approche procedurale : sur le serveur, chaque action de l'utilisateur peut etre liee a un 
evenement declencheur de l'execution d'un programme. 

Ce fonctionnement est tres efficace du point de vue du developpeur mais il peut avoir un effet 
pervers : celui de declencher plus de transactions client-serveur que necessaire. II est done conseille 
d' analyser attentivement les evenements a traiter sur le serveur pour eviter une degradation des 
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performances. C'est d'ailleurs pour cela que les evenements pris en charge par chaque controle sont 
limites aux actions les plus utiles (par exemple : Fevenement cl i ck est gere sur le serveur mais pas 
Fevenement OnMouseOver qui doit etre gere sur le client en ECMAScript). 

C'est aussi pour cette raison que certains evenements ne declenchent pas le renvoi (PostBack) imme- 
diat de la page (sauf parametrage explicite via la propriete booleenne AutoPostBack). Ces evenements 
sont mis en attente jusqu'a ce que la page soit effectivement renvoyee au serveur. Chaque evenement 
est alors traite dans un ordre indetermine, Fevenement ayant declenche le renvoi de la page (typiquement 
un clic) etant traite en dernier. 

ASP.NET permet au developpeur d'enrichir le modele d' evenements. Par ailleurs, certains evenements 
peuvent etre traites a la fois cote serveur et cote client (ECMAScript). 

Tableau descriptif des evenements 



Etape Evenement Description 


Initialisation 


Page_Ini t 


ASP.NET appelle cet evenement et restaure I'etat de la page 
et des controles (View State) ainsi que les donnees de 
PostBack. 


Chargement de la page 


Page_Load 


Chargement de la page. La propriete de page IsPostBack 
permet de savoir : 

- si la page est chargee pour la premiere fois. Le traitement 
consiste alors a initialiser, a generer la page, etc. ; 

- si la page est retournee suite a une action de I'utilisateur. 
Le traitement consiste alors a traiter cette reponse. 


Evenements specifiques 


Exemple : Buttonl_Cl i ck 


Traitement du code specifique de I'application lie a des eve- 
nements. 

La propriete de page IsVal id permet de savoir si I'ensem- 
ble des controles de validation ont retourne un resultat positif 
(true). 


Dechargement de la page 


Page_Unload 


Dechargement de la page. II est recommande de liberer 
explicitement les ressources utilisees : fermeture de fichiers, 
des bases de donnees, liberation des objets, etc. 



Les controles serveur 

Les controles serveur sont eux-memes de quatre types : 

• controles HTML serveur, 

• controles Web serveur, 

• controles de validation, 

• controles utilisateurs specifiques. 



Visual Studio.NET 

Meme s'il est interessant de connaitre la maniere dont sont codes ces differents elements au sein d'une page 
ASPX, Visual Studio.NET offre des fonctions extremement efficaces qui au mieux evitent au developpeur de devoir 
intervenir sur le code de presentation et au pire effectuent tout le travail de generation preliminaire. 
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Figure 15-7 

Modele objet des controles HTML serveur. 



Les controles HTML serveur 

Le code HTML standard qui compose une page est traite parASP.NET comme du texte litteral sans 
aucune signification. II est en particulier inaccessible aux programmes. Pour permettre aux deve- 
loppeurs d'interagir au niveau du serveur avec ces elements HTML, ASP.NET introduit la notion de 
controles HTML serveur. 

Ces controles se caracterisent de la maniere suivante dans les pages ASPX : 

• II s'agit de balises HTML classiques auxquelles est ajoute un attribut runat="server". 

• Chaque element doit disposer d'un attribut Id unique qui permet de le referencer dans les 
programmes. 

• Ces elements doivent obligatoirement etre contenus dans une balise HTML <form (...) 
runat="server">. 

A chaque balise HTML correspond une classe de l'espace de noms System. Web. U I. WebControls (par 
exemple : la classe Html Image correspond a la balise HTML <img>) qui implemente sous forme de 
proprietes les attributs des balises HTML. 
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Lorsque ASP.NET genere la classe correspondant a la page ASPX, il cree des instances d'objets pour 
chaque element HTML identifle comme un controle, dont le nom est Fid de la balise. II est ainsi 
possible de manipuler ces elements HTML et toutes leurs proprietes (y compris les styles) depuis les 
programmes en utilisant ces instances d'objets. 

Exemple : 



// code behind 
Message. InnerHtml 



"Hel 



<!-- page aspx --> 

<span id="Message" runat="server"/> 
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Figure 15-8 

Modele objet des controles Web serveur. 
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Les controles Web serveur 

Les controles Web serveur (classes de l'espace de noms System. Web. Ul.WebControls.WebControl) se 
distinguent des controles HTML serveur dans le sens ou il n'y a pas de correspondance exacte avec 
les balises HTML. Ces controles peuvent etre aussi simples qu'un bouton (classe Button) mais aussi 
plus complexes, comme des tables (classe DataGrid). 

Ces controles se caracterisent de la maniere suivante dans les pages ASPX : 

• II s'agit de balises XML bien formees qui referencent l'espace de noms ASP (prefixe <asp : >) et 
possedent obligatoirement un attribut runat="server". 

• Chaque element doit disposer d'un attribut Id unique qui permet de le referencer dans les 
programmes. 

• Ces elements doivent obligatoirement etre contenus dans une balise HTML <form (...) 
runat="server">. 

Exemple : 

<!-- Controle Web Server Textbox --> 

<asp:textbox id=TextBoxl runat="Server" Text="Hello" /> 

<!-- Controle Web Server DropDownList --> 
<asp:DropDownl_ist id=DropDownl runat="server"> 

<asp: Li st I tern Val ue="0">A</asp: Listltem> 

<asp: Li st I tern Val ue="l">B</asp: Listltem> 

<asp: List I tern Val ue="2">C</asp: Listltem> 

<asp: List I tern Val ue="3">D</asp: Listltem> 
</asp:DropDownList> 

Les controles de validation 

Comme leur nom Findique, les controles de validation permettent de tester qu'une saisie utilisateur 
est correcte et d'afficher les messages d'avertissements requis. Cette fonction represente un reel pas 
en avant car implementer un tel mecanisme necessite en temps normal beaucoup de travail. D'autant 
plus que ces controles s'adaptent reellement aux navigateurs : 

• en mode avance, les verifications sont effectuees sur le client par des scripts (ECMAScript) ; 

• en mode restreint, elles sont effectuees de maniere traditionnelle par le serveur et le resultat est 
renvoye au client en HTML 3.2. 



Controle serveur 

Pour des raisons de securite, les verifications sont systematiquement effectuees sur le serveur meme si elles ont 
deja ete realisees sur le client. 



Mais le developpeur n'a pas a se soucier de cette implementation HTML, il lui suffit juste de placer 
les controles sur la Web Form, de les associer a n'importe quel controle serveur de saisie, et de choisir 
le mode d'affichage des messages d'erreur. 
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Tableau des controles de validation 



Type de Controle de validation Description 
validation 


Entree requise 


Requi redFieldVal i da tor 


Verifie que I'utilisateur n'oublie pas un champ de saisie 
obligatoire. 


Comparaison avec 
une valeur 


CompareVal idator 


Compare une valeur de saisie avec une constante ou par 
rapport a la valeur d'une propriete d'un autre controle (=, <, 

>, <=, >=)■ 


Plage de valeurs 


RangeVal idator 


Verifie qu'une valeur de saisie est comprise entre une 
borne inferieure et une borne superieure. Les bornes peu- 
vent etre des nombres, des caracteres alphabetiques, ou 
des dates. 


Correspondence 
avec un modele 


Regul arExpressionVal idator 


Verifie qu'une valeur de saisie correspond a un modele 
defini par une expression reguliere, c'est-a-dire une 
sequence de caracteres bien definie telle qu'un numero de 
telephone ou un code postal. 


Personnalise 




CustomVal idator 


Verifie une valeur de saisie a partir d'un programme ecrit 
specifiquement. 



Les controles utilisateurs specifiques 

Les controles serveur livres avec le framework ne peuvent pas repondre a tous les besoins de deve- 
loppement. Microsoft suggere quatre strategies de creation de ses propres controles : 

• pour reutiliser un morceau d'interface utilisateur, il est recommande de creer un controle utilisateur 
(User Control) ; 

• pour etendre les fonctionnalites d'un controle existant, il est recommande de creer un controle 
specialise qui en herite et d' etendre ses methodes et proprietes ; 

• pour agreger plusieurs controles existants, il est recommande de creer un controle composite 
(Composite Control) ; 

• pour creer un nouveau controle de toute piece, il est recommande de creer un controle personnalise 
(Custom Control). 

La demarche de creation est propre a chaque type de controle : 

• Les controles utilisateurs ne sont rien d' autre que des Web Forms dont le fichier porte F extension 
ASCX, dans lesquelles on a retire les balises HTML HTML, BODY et FORM et remplace la directive de 
page par une directive de controle (©Control ). Le developpement d'un tel controle commence done 
par celui d'une Web Form classique qu'on modifie par la suite. 

• Les controles specialises sont des classes qui derivent d'une classe des espaces de noms 
System.Web.UI .WebControl s ou System. Web. Ill .Html Controls. 

• Les controles composites sont des classes qui derivent d'une classe des espaces de noms 
System.Web.UI. Control ou System.Web.UI .WebControl s .WebControl, qui implementent l'interface 
InamingContainer et specialisent la methode CreateChildControls. 
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• Les controles personnalises sont des classes qui derivent d'une classe de l'espace de noms 
System. Web. UI. Control et qui implemented une interface de conception (classes de l'espace de 
noms System. Web. UI .Design). 

II existe aussi une difference dans l'utilisation de ces controles : 

• Les controles utilisateurs sont compiles a 1' execution comme les pages ASPX. Leur usage est done 
moins confortable avec Visual Studio puisqu'ils n'ont pas de pages de proprietes ni d'interface de 
conception Wysiwyg. Enfin, ces controles doivent etre deployes avec chaque application qui les 
implementent. 

• Les autres controles sont des programmes qui offrent exactement le meme support de developpe- 
ment que les controles serveur fournis avec le framework (integres dans la boite a outils, pages de 
proprietes, interface Wysiwyg, etc.). 

Les Mobile Web Forms 

L'objectif des Mobile Web Forms est de permettre le developpement d' applications destinees a des 
peripheriques nomades tels que telephones portables, PDA, Pocket PC, etc. Microsoft a edite pour 
cela un SDK d'extension pourASP.NET et Visual Studio.NET qui contient : 

• un ensemble de controles serveur specifiques (Mobile Web Forms Controls) qui permettent de 
generer du WML 1.1 (WAP), du cHTML 1.0 (i-mode Japonais) ou du HTML 3.2 (PDA) ; 

• des nouvelles fonctions de detection et de prise en charge de navigateurs et de peripheriques ; 

• la prise en charge du developpement RAD de Visual Studio .NET ; 

• des simulateurs permettant de tester les differents navigateurs. 

Les applications pour mobiles sont des applications ASP.NET a part entiere, qui beneficient de toutes 
les fonctions et de tous les services du framework (securite, configuration, performances, etc.). 

Avec les Mobile Web Forms, la meme application peut etre utilisee pour plusieurs types de periphe- 
riques. Les interfaces generees sont en general suffisamment simples pour que le developpeur puisse 
s'appuyer entierement sur les controles sans avoir a ecrire une ligne de cHTML ou de WML. 

Le developpement de services Web avec Microsoft .NET 

Nous allons maintenant presenter les moyens et les strategies proposees par le framework .NET pour 
la mise en ceuvre de services Web et des applications clientes. Nous nous appuierons sur un exemple 
trivial d' application qui consiste a additionner deux chiffres. 

La generation d'un service Web 

La technique la plus rapide pour mettre en ceuvre ce service Web est d'utiliser F implementation four- 
nie par ASP.NET. Cette implementation permet de creer rapidement un service en utilisant trois 
protocoles : SOAP, HTTP-Get et HTTP-Post. 

Que ce soit en passant par le designer de Visual Studio.NET ou en effectuant le developpement 
sans assistance, la creation d'un service Web ASP.NET est a la fois simple et rapide. La couche 
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d' abstraction est suffisante pour que le developpeur se concentre sur la logique applicative sans se 
soucier des details techniques de SOAP et WSDL. 

Abstraction ne veut pas dire boite noire : il ne s'agit pas de cacher 1' implementation technique mais 
d' assurer plus de productivite en assistant la generation de code. 

La methode assistee de developpement 

La methode la plus simple et la plus rapide pour creer un service Web ASP.NET consiste a utiliser les 
assistants de TIDE Visual Studio.NET. 

II faut d'abord commencer par creer un nouveau projet (voir figure 15-9) et choisir un langage de 
programmation. Nous choisissons dans le cas present le langage C#, mais les autres langages compa- 
tibles .NET peuvent tout aussi bien etre utilises. Parmi les projets types proposes par Visual Studio, 
nous choisissons ASP.NET Web Service. 

Le service Web est appele WSCalculatrice:il est installe surle serveurllS local http ://localhost comme 
cela est propose par defaut. 



New Project 



Project Types: 



Templates: 
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A project for creating XML Web services to use from other applications 
Name: | WSCalculatrice 

Location: 






|http://localhost/WSCalculatrice 
Project will be created at http ://localhost/ WSCalculatrice 
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Figure 15-9 

Creation d'un projet de service Web ASP.NET. 



Automatiquement, VisualStudio.NET cree un fichier Systemel . asmx pour le service Web et un fichier 
code behind Systemel.asmx.es qui contient le code d' implementation en C# (voir figure 15-10). Le 
fichier ASMX est le point d' entree du service Web : ce fichier doit etre interroge en HTTP pour acceder 
au service. 



La plate-forme .NET 

Chapitre 15 



L-1'.'JAMM.IMW im^-mm ,IH»B,a!.., UI..L.I.I 

Hf \-jit Vh-vv Ufirtjrrt tf^ 1 |j*i.ig rnrJ-: Wrwirnu hb-V 

,:P T _l ■ i£ H Jt Ife © *T - m . £] . EH > IWiufl 

Q%^« * iF - l i ^ ** % ft. 

51*1 P«lje | 5or«.rl «n< .u L'>iV l J ft*T*.eI-«Mim.i.'i J 



^Sit^i- 



S i:.i i rig SyaUSAJ | 

U3J.UU SyPCWi Cull el:!, lutu.- 

uamg System. Compane nt Ho aeu 

H.nnO [5y.itnn.. Dri!: n; 

i.i ; ljtg 3ys\. era . n 1 ayrLU 3 tlCS J 

usina System.. u e&; 

lining ^y.ifcnn.. Urb . 3r rvi rr.:i ; 

I I namespace WSCalGulacrice 



^ir^ 






/// « 
/// Su 

/// a 

public 



irrr.i.UrbSrrvlir: 



V description toe Servicel. 

ory? 

.in [Jrrvlrrl : iiy.if.rm.Urh.3n 

public SCEVlCCl [) 
( 

//tTOBCGEK: Thia call is l=l]ij1l=J by Uie A3P-KET Veb Services IiciLgnei 

Initial isstoTnparLent.<) ; 



Coi ponenc ^eai'tnsr rreneraxea codej 



// WES 5IBUHE EMJLKPLE 

/,■■' The HellDtforlLlI) e«smpie service returns the scrino; Hello Uorld 

// Lc buildr uncoameat tae IoIlouina lines Chen save and build trie project 

// Tra r.r.it Chin irh .irr^rr, prr.i.i TTi 



public string Fur ] Inlfnr Id ^ 



cecum "' Hello World". 



=1 3 71 EH) . -j| e, 



OS3 

■:•. 7 - 






S Sdutton ■wscakulatrKe' (I project) 
I-.! T* WSCalcdatrtce 

■ , a9 fl (fa HIGH 

J fisserriHyirrfo.cs 

ijtf] Uobal.aHX 

*j] MmonL.asHiK 

jl Wrjb.eorrfig 

*5 WH" rln«Tirr,.Whrn 



r 



S Mutton Erefclw I ^ ct«£ vww I 



PrLpertici 



» > 



_ 



I 



s^v^sJe^ 



»,-= 



Figure 15-10 

Apergu d'un sendee Web genere par VisualStudio.NET. 



Le fichier d' implementation C# qui a ete genere pour le service contient un exemple de code en 
commentaire qui explique comment poursuivre le reste du developpement : il suffit d'enlever ces 
commentaires pour disposer immediatement d'un service Web fonctionnel avec une methode 
Hel 1 oWorl d( ) qui retourne la chaine de caracteres "Hel 1 o Worl d" : 

[WebMethod] 

public string HelloWorldO 

{ 

return "Hel lo World" ; 
} 

Pour implementer notre exemple, il suffit done de modifier le code precedent de la maniere suivante 
(voir figure 15-11) : 
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la classe Servi eel est renommee CCal cul atri ce (ne pas oublier de modifier du meme coup le construe - 
teur, e'est-a-dire la methode qui porte le meme nom que la classe) ; 

la methode HelloWorldO est renommee AdditionO et le code de la methode est modifie en conse- 
quence. 



Commentaires XML 

Les commentaires sont ajoutes en XML en utilisant la suite de caracteres « /// ». L'IDE se charge de rajouter auto- 
matiquement le tag <summary>. Cette fonctionnalite n'existe qu'en C# et permet de generer une documentation 
XML complete et consultable grace a des feuilles XSL fournies. 
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Figure 15-11 

Implementation du service Web. 
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Le developpement est termine, il ne reste plus qu'a compiler le programme et a l'executer. Une 
instance d' Internet Explorer est automatiquement lancee pour interroger le service a l'adresse 
http://localhost/WSCalculatrice/Service1.asmx (voir figure 15-12) : 
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Figure 15-12 

Interrogation du service Web sous Internet Explorer. 



La generation d'un service Web par ASP.NET inclut systematiquement une page HTML qui 
offre une description complete du service. On y trouve en particulier les extraits du fichier 
WSDL qui concernent 1' implementation des trois protocoles SOAP, HTTP-Get et HTTP-Post. 
Ce fichier WSDL est accessible dans sa totalite par le biais d'un lien hypertexte de la page (voir 
figure 15-13). 
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Figure 15-13 

Contenu dufichier WSDL du service Web. 



L'environnement genere egalement une page qui pennet d'interagir avec le service Web nouvelle- 
ment cree (voir figure 15-14). 

La page d' interaction propose de tester les methodes du service, en l'occurrence la methode Addi - 
t1 on ( ) que nous venons d'implementer (voir figure 15-14) : un formulaire HTML permet de saisir 
les deux parametres i et j de la methode Addition () et de les soumettre grace au bouton Invoke. 
Ce test n'est realisable que parce que le protocole HTTP-Get a ete implemente automatiquement, 
en plus de SOAP. De ce fait, le service peut etre interroge par le biais d'une simple URL en passant 
les parametres par paires de valeurs. Le resultat de ce test est un document XML affiche directe- 
ment par Internet Explorer : 

|<?xml version="1.0" encoding="utf-8"?> 
<int xmlns="HTTP://tempuri .org/">8</int> 
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Figure 15-14 

Interaction de test avec un service Web. 



On note immediatement que le vocabulaire XML utilise par ce document est http://tempuri.org (a ne 
pas confondre avec l'espace de noms WSCalculatrice de notre classe C#). II s'agit en fait d'une 
valeur par defaut que Visual Studio a affectee au service, et si nous revenons a l'ecran principal 
(figure 15-12), nous pouvons d'ailleurs lire un avertissement a ce sujet. Nous pouvons definir un 
vocabulaire XML specifique par le biais de l'attribut [WebService] (voir figure 15-15). Cet attri- 
but et l'attribut [WebMethod] permettent de specifier un certain nombre de proprietes du service 
comme le montre l'exemple suivant (nous reviendrons en detail sur ces attributs dans la section 
« Detail de la creation d'un service Web »). 
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Figure 15-15 

Implementation des attributs [WebMethod] et [WebSen'ice]. 

Un nouveau test permet d'apprecier le resultat tant au niveau de 1'ecran principal (figure 15-16) ou le 
message d'alerte a disparu que du resultat d'invocation de la methode (figure 15-17). 



Detail de la creation d'un service Web 

Les assistants sont interessants pour leurs gains de productivite mais ils donnent souvent l'impression 
d' avoir affaire a des boites noires complexes et mysterieuses. II est pourtant interessant de connaitre 
et de comprendre les details d' implementation, d'autant que la creation d'un service Web en 
ASP.NET demeure tres simple meme lorsqu'on ne dispose que d'un editeur de texte. 

La declaration du service 

ASP.NET permet d'acceder a un service Web a partir d'un fichier dont l'extension est .asmx. L'inter- 
rogation de ce fichier est assez equivalente a celle d'une page ASPX (voir la section « Une instance 
de Page ») : la premiere interrogation du service declenche la generation d'un code source qui imple- 
mente une classe et 1' interface du service. Ce code est compile et le programme resultant est place 
dans un repertoire temporaire pour repondre aux requetes suivantes. 
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Figure 15-16 

Ecran principal du service Web. 
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Figure 15-17 

Nouvel ecran d 'interaction avec le service Web. 
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Le fichier ASMX doit obligatoirement commencer par une directive @WebServi ce : 

| <% ©WebService Language="C#" CI ass="WSCalculatrice.Ccalculatrice" %> 

Cette directive permet d'indiquer le langage utilise et la classe qui implemente le service. 

Le code de cette classe peut etre inclus dans le fichier ASMX comme l'exprime l'exemple precedent ou 
deporte dans un fichier externe de deux manieres : 

• dans un programme externe compile (un assemblage) ; 

• dans un fichier de code-behind a la maniere des pages ASPX. 

L'exemple suivant montre comment utiliser un assemblage MonAssemblage.dll qui doit obligatoire- 
ment etre enregistre dans un sous-repertoire Bi n de F application Web : 

<% ©WebService Language="C#" CI ass="WSCalculatrice.Ccalcul atrice, MonAssemblage.dll" %> 



Designation de I'assemblage 

La designation de I'assemblage n'est pas obligatoire mais elle evite une recherche de la classe d'implementation 
dans tous les fichiers du sous-repertoire Bi n au moment de I'invocation du service, d'ou un gain de performance. 



Lutilisation d'un fichier de code-behind est la methode utilisee dans le chapitre precedent lorsque 
Visual Studio genere le service. Le fichier Servi eel . asmx etait alors reduit a une ligne unique : 

I<% ©WebService Language="C#" Codebehind="Servicel .asmx.es" 
Class="WSCalculatrice.CCalculatrice" %> 

Les deux methodes sont d'une certaine maniere identiques puisque, comme nous l'avons vu en intro- 
duction, ASP.NET finira par compiler et generer un assemblage contenant le code du service des la 
premiere interrogation de la page ASMX. 

Le developpement de la classe qui implemente le service Web peut ensuite debuter. En general, mais 
e'est optionnel, cette classe derive de la classe System. Web. Services qui lui permet d'acceder aux 
objets communs d' ASP.NET qui sont : 

• Appl i cati on et Sessi on, qui permettent de gerer les variables et les etats de session ; 

• User, qui permet d'acceder a l'identite de l'utilisateur si la demande d'authentification est active ; 

• Context, qui permet d'acceder a toutes les informations relatives au dialogue HTTP en cours. 

Toujours en option, il est egalement possible d'utiliser l'attribut [WebService] qui permet de decrire 
certaines proprietes comme le nom, l'espace de noms ainsi que la description du service. Cette utili- 
sation a ete illustree dans le chapitre precedent et est mise en ceuvre de la maniere suivante : 

<% @WebService Language="C#" CI ass="WSCalculatrice.CCalcul atrice" %> 

using System. Web. Services; 

namespace WSCal cul atrice { 

[WebService (Name="Ma Cal culatrice" , 
Description="Une Calculatrice permettant de faire une addition", 
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Namespace=" www. monDomaine.com")] 

public class Ccalculatrice: WebService { 

// definition des methodes 
) 
} 

La declaration des methodes du service 

Une fois la classe du service Web correctement declaree, il ne reste plus qu'a implementer ses metho- 
des. Pour qu'une methode soit accessible par 1' interface du service Web, il faut : 

• la declarer comme etant Publ i c ; 

• utiliserl'attribut [WebMethod]. 

Cet attribut permet d'indiquer au compilateur et au CLR que la methode implemented est exposee 
comme une operation du service Web. II permet ensuite de preciser certaines caracteristiques de la 
methode dont son nom (MessageName) et une description (Description). 

Ceci etant fait, le developpement est termine et le service Web est fin pret pour etre deploye et teste. 
<% ©WebService Language="C#" Class="WSCalculatrice.CCalculatrice" %> 

using System. Web. Services; 

namespace WSCalculatrice { 

[WebService (Name="Ma Calculatrice" , 
Description="Une Calculatrice permettant de faire une addition". 
Namespace^" www. monDomaine.com")] 

public class CCalculatrice: WebService { 
[WebMethod (MessageName="Additionner" , 
Description="Effectue 1 'addition de 2 entiers")] 
public int Addition (int i, int j) { 

return i+j; 
} 
) //CCalcularice 
} 

Le deploiement du service 

Pour que le deploiement du service soit realise, les fichiers d'implementation du service doivent etre 
copies dans un repertoire virtuel IIS : c'est, au minimum, une page ASMX mais il peut y avoir aussi, 
comme nous Favons vu precedemment, des assemblages (dl 1 copiees dans un sous-repertoire Bi n) ou 
des fichiers de code -behind si le developpeur en a specifies. 

En option, il est possible de rajouter un fichier de configuration XML Web . conf i g, comme c'est le cas 
pour toute application ASP.NET. 

Enfin, il faut permettre la decouverte du service Web en creant le fichier WSDL de description. Ce 
fichier peut-etre cree a partir d'un utilitaire fourni dans le SDK du framework .NET: disco.exe. 
L'exemple suivant genere les fichiers XML de decouverte . di sco, .wsdl et . di scomap de notre service : 

Disco.exe HTTP: //I ocal host/WSCalculatrice/Servicel .asmx 
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La generation d'un proxy en C# 

Le proxy est un composant logiciel charge de transformer les appels du client en messages SOAP, de 
les envoyer au service et de recuperet - les reponses contenant le resultat. 

Le developpement d'un proxy d'un service Web existant est totalement pris en charge par les assistants 
de Visual Studio.NET. Nous allons illustrer la demarche par le developpement d'une petite application 
Web ASP.NET qui va nous permettre d'exploiter le service Ma Cal cul atri ce du chapitre precedent. 

Meme en se passant de Visual Studio .NET, le developpement d'un proxy est assiste puisque le SDK 
propose un utilitaire WSDL . exe en ligne de commande qui permet de generer automatiquement le code 
source du proxy en C#, en Visual Basic .NET ou en JS.NET, et ceci pour tout service Web existant. 
(voir chapitre 13 « Principes de mise en ceuvre »). 

La methode assistee de developpement 

Commencons d'abord par creer un nouveau projet C#, en choisissant parmi les modeles proposes. 
Dans le cas present, nous allons creer un petit site ASP.NET contenant un formulaire HTML qui 
permet d'interroger notre service et d'afficher le resultat. Le projet est done du type « ASP.NET Web 
Application » (voir figure 15-18). 

Le site s'appelle par defaut WebAppl i cati onl et se trouve installe sur le serveur IIS local http://localhost. 



Project Types: 



Templates: 
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A project for creating an application with a Web user interface 
Name: Web Application 1 
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Project will be created at http://localhost/WebApplicationl. 
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Figure 15-18 

Creation d'un projet application Web ASP.NET. 



Les services Web doivent etre inclus dans un projet au meme titre que des composants COM ou 
.NET, a la seule difference qu'il s'agit ici d'ajouter une reference non pas locale mais disponible via 
Internet (menu « Ajouter une reference Web »). 

Les services Web publies sur les annuaires UDDI sont consultables directement a partir de Visual 
Studio (figure 15-19). Des que le service est decouvert, Visual Studio affiche les informations 
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fournies par les documents WSDL (voir figure 15-20) ou permet de consulter les documents WSDL 
eux-memes. Lorsque la recherche est terminee, un bouton permet de selectionner le service Web 
interroge et d'en faire une reference du projet. 
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Figure 15-19 

Recherche de services Web via les annuaires UDDI a partir de VisualStudio.NET. 
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Figure 15-20 

Decouverte d'un sen'ice Web dans VisuaIStudio.NET. 
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L'etape suivante consiste a creer rapidement une interface de test (voir figure 15-21). Dans la barre 
d'outils, nous faisons glisser deux controles TextBox, un Button et un Label dont nous changeons le 
texte en Resultat. Nous ne changeons pas la designation de ces controles qui s'appellent done 
respectivement : TextBoxl, TextBox2, Buttonl et Label 1. 



Developpement RAD 

Cette technique de developpement rapide n'a rien d'exceptionnel pour des developpeurs Visual Basic, mais nul 
doute que les developpeurs C++ ou ASP apprecieront les possibilit.es offertes par Visual Studio.NET 
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Figure 15-21 

Conception d'unformulaire HTML sous VisualStudio.NET. 

Un double-clic sur le bouton permet d'atteindre le code de l'evenement CI ick implements dans la 
methode Buttonl_Cl 1ck(). L'objectif de cette action sur le bouton est d'interroger le service Web et 
nous devons done d'abord creer une instance de la classe proxy du service : 



Local host. Macalculatrice myCalc = new local host. Macalculatrice( ) ; 
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II ne reste plus ensuite qu'a appeler la methode AdditionO du service, methode exposee par la 
classe proxy. Ceci est d'autant plus facile a realiser que la fonction IntelliSense de FIDE est active 
y compris sur les services Web (voir figure 15-22) : 
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Figure 15-22 

Fonction Intellisense sur une methode de service Web. 

Le reste du developpement consiste a passer en parametre de la methode Addi ti on ( ) les deux valeurs 
saisies dans les controles TextBox, puis a recuperer le resultat et 1'afficher dans le controle Label 
comme le montre l'exemple suivant : 

Private void Buttonl_Click(object sender. System. EventArgs e) 
{ 

local host. Macalcul arice myCalc = new local host. Macalculatrice( ) ; 

int re = myCal c.Addition(int.Parse(TextBoxl.Text) , int. Parse(TextBox2. Text)) ; 

Labell.Text = rc.ToStringt ) ; 
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II suffit ensuite de compiler et d'executer le programme pour que Visual Studio lance une instance 
d' Internet Explorer et affiche le formulaire HTML qui permet d'interroger notre service Web (voir 
figure 15-23) : 
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Figure15-23 

Exemple de test du service Web depute notre application Web. 



Guide de developpement 

Dans la section suivante, nous allons detailler plus precisement quelques elements techniques lies au 
developpement de services Web avec le framework .NET. 

La directive @WebService 

Cette directive doit obligatoirement etre placee au debut des fichiers ASMX et possede les attributs 
suivants : 

• CI ass (obligatoire) est une chaine de caracteres qui permet de declarer la classe d'implementation 
du service Web. Cette classe peut etre implemented dans le fichier ASMX lui-meme ou dans un 
assemblage separe qui doit, dans ce cas, se trouver dans un sous-repertoire /Bin. 
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• CodeBehind est une chaine de caracteres qui permet de declarer le fichier source dans lequel est 
implemented la classe du service Web (dans l'hypothese oil celle-ci n'est implemented ni dans le 
fichier ASMX, ni dans un assemblage). 

• Debug est un booleen qui permet d'indiquer si le service Web est compile avec les symboles de 
debug. 

• Language est une chaine de caracteres qui permet de declarer au compilateur le langage utilise dans 
le fichier ASMX : C#, VB, JS, etc. 

Lattribut [WebService] 

Cet attribut est optionnel et peut etre applique a la classe qui implemente le service Web. 
II possede les proprietes suivantes : 

• Descri pti on, une chaine de caracteres qui permet de preciser un message de description ; 

• Name, une chaine de caracteres qui permet de nommer le service ; 

• NameSpace, une chaine de caracteres qui permet de preciser l'espace de noms XML du service Web. 
II est fortement recommande de modifier cette propriete puisque sa valeur par defaut est http:// 
tempuri.org. 

Lattribut [WebMethod] 

Cet attribut doit obligatoirement etre applique aux methodes exposees par le service Web. 

II possede les proprietes suivantes : 

• BufferResponse est un booleen qui a par defaut la valeur True. Dans ce cas, la reponse de la 
methode est serialised dans un buffer jusqu'a ce que la reponse soit complete ou le buffer plein. Ce 
parametrage permet d'augmenter les performances dans le cas d'une reponse de taille reduite. En 
revanche, dans le cas d'une reponse trop lourde, il est preferable d'indiquer une valeur Fal se, ce 
qui a pour effet de retourner les donnees dans un flux constant (par exemple : serialiser un gros 
fichier XML et retourner le resultat ligne apres ligne). 

• CacheDuration est un entier qui permet d'indiquer le nombre de secondes pendant lesquelles la 
reponse de la methode est maintenue en cache. Par defaut, aucun cache n'est utilise et cette valeur 
est 0. 

• Descri pti on est une chaine de caracteres qui permet de preciser un message de description. 

• EnableSession est un booleen qui a par defaut la valeur False. II permet d'indiquer si la gestion 
d'etats de session doit etre activee. Si cette gestion est activee, la methode doit obligatoirement 
heriterde la classe System. Web. Services. 

• MessageName est une chaine de caracteres qui permet de modifier le nom expose par la methode (par 
defaut, le nom de la methode elle-meme). 
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• Transacti onOpti on est un enumerateur dont la valeur est decrite dans le tableau ci-apres. II permet 
d'indiquer si la methode s'execute dans le cadre d'une transaction (MTS). 

Tableau des valeurs deTransactionOption 



Valeur Description 


Disabled 


Indique que la methode ne s'execute pas dans le cadre d'une transaction. 


NotSupported 


Idem. 


Supported 


Idem. 


Required 


Indique que la methode du service Web requiere une transaction. Etant donne que les methodes 
de services Web ne peuvent participer a une transaction qu'en tant qu'objet racine, une nouvelle 
transaction est creee. 


RequiresNew 


Indique que la methode du service Web requiert la creation d'une nouvelle transaction. 



Les services d'extension SOAP 

Les services d'extension permettent de modifier le contenu du message SOAP. Cela se realise en inte- 
grant du code specifique avant et/ou apres la serialisation et la deserialisation d'un message. Cette 
fonctionnalite permet par exemple d'ajouter un service annexe de cryptage, de compression, de trace, 
etc. 

Pour ajouter un tel service, il est necessaire de suivre les etapes suivantes : 

l.Creer une classe d'extension qui doit heriter de SoapExtension (espace de noms 
System. Web. Services .Protocol s) . 

2. Specialiser la methode ChainStream pour sauvegarder une reference du flux original passe en 
parametre et creer un nouveau flux retourne par la methode (ces flux correspondent respective - 
ment aux flux 1 et flux 2 de la figure 15-24). Ces references serviront dans les traitements ulte- 
rieurs a lire les messages SOAP. 

3. Initialiser le service en specialisant les methodes Get Initializer et Initialize. 

4. Specialiser la methode ProcessMessage pour implementer les fonctions du service en fonction des 
etapes de traitement du message SOAP: BeforeDeserialize, AfterDeserialize, BeforeSeria- 

1 ize, AfterSerial ize 

5. Configurer le service d'extension, soit en creant un attribut de methode specifique, c'est-a-dire 
une classe heritant de SoapExtensionAttribute, soit a partir du fichier de configuration pour 
l'ensemble des methodes du service Web. 

Pour mieux comprendre cette implementation, il est necessaire de decrire l'ordre dans lequel sont 
executees les differentes methodes (voir figure 15-24). Cette execution est decrite a la fois sur le 
client et sur le serveur puisque les deux acteurs sont concernes : qui dit extension, dit specificites 
qui doivent done etre implementees a la fois sur le serveur et sur le client. Bien evidemment, le 
client et le serveur n'utilisent pas obligatoirement les memes langages/technologies mais dans 
notre explication, nous partons du principe que tout peut aussi etre developpe en .NET. 
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Lorsqu'un client invoque le service : 

II appelle une methode de la classe proxy. 

Une nouvelle instance de l'extension SOAP extension est creee. 

Au premier appel de l'extension SOAP pour ce service Web, la methode Getlnitializer est 
executee et le resultat mis en cache. 

La methode Initialize est invoquee. 

La methode ChainStream est invoquee. 

La methode ProcessMessage est invoquee al'etape BeforeSerialize. 

ASP.NET serialise les arguments de la methode du service Web en XML. 

La methode ProcessMessage est invoquee a l'etape AfterSerial ize. 

ASP.NET envoie le message SOAP au serveur Web qui heberge le service Web. 

Lorsque le serveur recoit la requete : 

ASP.NET recoit le message SOAP. 

Une nouvelle instance de l'extension SOAP extension est creee. 

Au premier appel de l'extension SOAP pour ce service Web, la methode Getlnitializer est 
executee et le resultat mis en cache. 

La methode Initialize est invoquee. 

La methode ChainStream est invoquee. 

La methode ProcessMessage est invoquee a l'etape Bef oreDeseri al i ze. 

ASP.NET deserialise les arguments dans le message XML. 

La methode ProcessMessage est invoquee al'etape AfterDeserialize. 

ASP.NET cree une nouvelle instance de classe du service Web et invoque la methode en lui passant 
les arguments deserialises. La methode est executee. 

La methode ProcessMessage est invoquee al'etape BeforeSerialize. 

ASP.NET serialise la valeur de retour et les parametres en XML. 

La methode ProcessMessage est invoquee al'etape AfterSerial ize. 

ASP.NET envoie le message de reponse SOAP au client. 

Enfin, lorsque le client receptionne la reponse : 

ASP.NET recoit le message SOAP sur le client. 

La methode ProcessMessage est invoquee al'etape Bef oreDeseri al ize. 

ASP.NET deserialise le message XML. 

La methode ProcessMessage est invoquee al'etape AfterDeserialize. 

ASP.NET passe la valeur de retour et les parametres a 1' instance de classe du proxy. 
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Figure 15-24 

Implementation serveur d'un service a" extension SOAP. 



Une implementation type d'un service d'extension sur le serveur est la suivante : 

using System; 

using System. Xml ; 

using System. Web. Services; 

using System. Web. Services. Protocols; 

public class MonExtension : SoapExtension { 
Stream oldStream; // flux 1 
Stream newStream; // flux 2 

// Si le service d'extension est invoque par le biais 

// d'un attribut specifique, cette methode permet de recuperer 

// cet attribut et ses parametres specifiques. 

public override object GetlnitializerCLogicalMethodlnfo methodlnfo, SoapExtensionAttribute 

^•attribute) { 
return attribute; 

} 
// Si le service d'extension est invoque par le biais 
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II du fichier de configuration web.config, cette methode permet de 
// recuperer le type de la classe du service Web 
public override object Getlnitializerdype t) { 
return typeof (MonExtension) ; 



// Cette methode d'initial isation recupere en parametre le resultat de la 
// methode Getlnitializer (qui peut etre en cache), 
public override void Initial izeCobject initializer) { 
MonExtensionAttribute attribute = (MonExtensionAttribute) initializer; 
// traitement specifique 
// (...) 
return; 
} 

// Traitement a proprement parler du service d'extension 
// en fonction des etapes, la lecture est realisee depuis oldStream 
// et l'ecriture s'effectue dans newStream ou inversement. 
public override void ProcessMessage(SoapMessage message) { 
switch (message. Stage) { 

case SoapMessageStage.BeforeSerial ize: 
// traitement specifique si necessaire 
// (...) 

// Copy(newStream, oldStream) 
break; 

case SoapMessageStage.AfterSerialize: 
// traitement specifique si necessaire 
// (...) 

// Copy(newStream, oldStream) 
break; 

case SoapMessageStage.BeforeDeserialize: 
// traitement specifique si necessaire 
// (...) 

// Copy(oldStream, newStream) 
break; 

case SoapMessageStage.AfterDeserial ize: 
// traitement specifique si necessaire 
// (...) 

// Copy(oldStream, newStream) 
break; 

default: 
throw new ExceptionC'etape i rival ide "); 
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II sauvegarde des references de flux pour un usage ulterieur 
public override Stream ChainStreamt Stream stream ) { 
oldStream = stream; // flux 1 
newStream = new MemoryStream( ) ; // flux 2 
return newStream; 
} 

// copie de flux 

void Copy(Stream from, Stream to) { 
TextReader reader = new StreamReader(from) ; 
TextWriter writer = new StreamWriter(to) ; 
writer.WriteLinet reader. ReadToEndt ) ) ; 
writer. Fl ush( ) ; 
} 
) 

La configuration d'un tel service d' extension peut etre realisee a partir d'un attribut specifique de 
methode. L' implementation type d'un tel attribut est la suivante : 

[AttributeUsage(AttributeTargets.Method)] 

public class MonExtensionAttribute : SoapExtensionAttribute { 

private int priority; //obi igatoi re 

private string maPropriete; // specifique 

public override Type ExtensionType { 

get ( return typeof (EncryptionExtension) ; } 
} 

public override int Priority { 

get { return priority; } 

set ( priority = value; } 
} 

// Implementation de proprietes specifiques 
public string MaPropriete { 

get ( return maPropriete; } 

set { maPropriete = value; } 
} 
) 

Cet attribut peut ensuite etre utilise sur une methode en particulier pour declencher le service 
d' extension : 

<@WebService Language="c#" Class="Test" %> 
II (...) 

public class Test{ 
[WebMethod] 
[MonExtension(MaPropriete="essai ")] 
public void MethodeTest( ) { 

// Implementation ... 
} 
) 
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L' autre solution consiste a passer par le flchier web.config (ou machine. config) mais cette methode 
ne permet de parameter le service d' extension SOAP qu'au niveau du service Web pour toutes ses 
methodes. Exemple : 

<configuration> 
<system.web> 
<webServices> 
<soapExtensionTypes> 

<add type="MonEspace.MonExtension, monExtension" Priority="l" Group="0" /> 
</ soapExtensionTypes> 
</webServices> 
</system.web> 
</configuration> 

Le parametre Group permet d'organiser les services d' extension SOAP en trois groupes : 

• le groupe de valeur ; 

• le groupe des services configures par le biais d'attributs ; 

• le groupe de valeur 1. 

Le groupe 1 a la priorite la plus faible. Au sein de chaque groupe, le parametre Priority permet de 
fixer un ordre d'execution, la valeur etant la priorite la plus elevee. 

La configuration d'un service Web 

Comme toute application ASP.NET, un service Web peut etre configure a partir d'un fichier web .config. 
Celui-ci contient une section specifique <webServi ces> dont la syntaxe XML est la suivante : 
<webServices> 
<protocols> 

<add name="protocol name" /> 
</protocols> 
<serviceDescript ion Format ExtensionTypes> 

<add type="extension class" /> 
</serviceDescriptionFormatExtensionTypes> 
<soapExtensionTypes> 

<add type="type" Priority="0 ou +" Group="groupe ou 1" /> 
</soapExtensionTypes> 
<soapExtensionReflectorTypes> 

<add type="type" /> 
</soapExtensionReflectorTypes> 
<soapExtensionImporterTypes> 

<add type="type" /> 
</soapExtensionImporterTypes> 
<wsdlHelpGenerator href="help generator file"/> 
</webServices> 

L'utilitaire Disco.exe 

Cet utilitaire permet de generer tous les fichiers de description ( . wsdl , .disco, . xsd et . di scomap) d'un 
service Web. II est utilise en ligne de commande en precisant FURL du service et des options : 

] Disco.exe <option> <URL> 
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Les parametres optionnels sont les suivants : 

/domain :<domaine> ou /d:<domaine> : specifie le domaine d'authentificationrequis parle serveur ; 

/user:<NomUtilisateur> ou /u:<NomUtil isateur> : specifie le nom d'utilisateur lors de l'authenti- 
fication par le serveur ; 

/password :<MotDePasse> ou /p:<MotDePasse> : specifie le mot de passe d'authentification requis 
par le serveur ; 

/nosave : ne sauvegarde pas sur le disque les documents de decouverte (.wsdl, .disco, .xsd et 
.discomap) ; 

/nol ogo : supprime la banniere Microsoft affichee au demarrage ; 

/out:<NomRepertoire> ou /o:<NomRepertoi re> : specifie le repertoire dans lequel doivent etre 
sauves les documents. Par defaut, il s'agit du repertoire courant ; 

/proxy :<URL> : specifie FURL du proxy-serveur qui doit etre utilise pour les requetes HTTP. Par 
defaut, la configuration du systeme est utilisee ; 

/proxydomain:<domaine> ou /pd:<domaine> : specifie le domaine d'authentification requis par le 
proxy-serveur ; 

/proxypassword:<MotDePasse> ou /pp:<MotDePasse> : specifie le mot de passe d'authentification 
requis par le proxy-serveur ; 

/proxyusername:<NomUtilisateur> ou /pu: <NomUti 1 isateur> : specifie le nom d'utilisateur lors de 
l'authentification par le proxy-serveur ; 

/? : affiche l'aide de l'outil. 



LutilitaireWSDL.exe 

Cet utilitaire permet de generer le code source du proxy d'un service Web dans un langage pris en 
charge par le framework .NET Cet utilitaire est decrit en detail chapitre 13. 



WSE (Web Service Enhancements) 1.0 pour Microsoft.NET 

Le SDK du framework.NET et Visual Studio.NET ont tres vite ete depasses par le developpement 
constant des specifications relatives aux services Web. En l'occurrence, trois d'entre elles ne sont pas 
prises en charge par la version originale du framework : 

• WS-Security, 

• WS-Routing, 

• WS-Attachments. 

Microsoft etait done oblige de remettre a niveau ses outils de developpement et ceci s'est traduit par 
la publication du WSE ( Web Service Enhancements) 1.0 pour Microsoft.NET 

Dans le detail, le WSE est : 

• une extension de la librairie objet du framework (Framework Class Library) qui permet a travers la 
nouvelle classe SoapContext d'implementer les specifications de WS-Security, DIME 
(WS-Attachments), et WS-Routing ; 

• un service de routage specifique permettant de construire une architecture de routage des messages 
SOAP (WS-Routing). 
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La mise en ceuvre de WSE 



Une fois le WSE installe, sa mise en ceuvre est realisee de maniere differente selon que Ton deve- 
loppe un programme client ou serveur. Dans tous les cas, l'objectif est de pouvoir acceder a un objet 
de type SoapContext. 

Le developpement client 

Pour un client, c'est-a-dire un programme destine a consommer un service Web, il faut d'abord modi- 
fier la classe proxy pour qu'elle herite de Web. Services. WebServlcesCHentProtocol. Cet heritage 
ajoute au proxy deux proprietes qui permettent d'acceder a un objet de type SoapContext : 

• RequestSoapContext pour le message SOAP de requete ; 

• ResponseSoapContext pour le message SOAP de reponse. 

Le developpement serveur 

Cote serveur, la mise en ceuvre commence par la modification du fichier XML de configuration 
Web.config du service Web afin d'ajouter un service d' extension SOAP (voir la section « Guide de 
developpement »). Exemple : 

<configuration> 
<system.web> 
<webServices> 
<soapExtensionTypes> 
<add ty pe= " Mi crosof t. Web. Services. WebServ ices Extension, 
Microsoft. Web. Services, Version=l. 0.0.0, Cul ture=neutral , 
PublicKeyToken=31bf3856ad364e35" priority="l" group="0'7> 
</soapExtensionTypes> 
</webServices> 
</system.web> 
</configuration> 

Une fois cette modification realisee, le programme qui implemente le service Web peut acceder a un objet 
HttpSoapContext dont deux proprietes statiques permettent d'obtenir un objet de type SoapContext : 

• RequestContext pour les messages SOAP de requete ; 

• ResponseContext pour les messages SOAP de reponse. 

WSE et la specification WS-Security 

L'objectif de la specification WS-Security est de securiser l'utilisation des services Web puisque 
l'utilisation du protocole SSL n'est possible et suffisante que dans des configurations simples oil les 
echanges sont realises de point a point. Dans le cadre d'une architecture orientee services plus 
complexe impliquant une agregation et une dissemination de plusieurs services Web, il est done 
necessaire d'utiliser d'autres techniques pour garantir : 

• l'authentification des parties ; 

• le cryptage des informations transmises ; 

• le controle d'integrite du message. 

Tous ces sujets sont traites en detail chapitre 19. 
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WSE et la specification DIME (WS-Attachments) 

WS -Attachments (http://msdn. microsoft. com/library/en-us/dnglobspec/html/wsattachmentsindex. asp) est une 
specification proposee par IBM et Microsoft qui permet a des services Web de transmettre ou de rece- 
voir des documents (binaires, images, fragments XML, etc.) sous forme de pieces attachees. Cette 
specification prevoit d'utiliser DIME (Direct Internet Message Encapsulation) - voir http://msdn.micro- 
soft.com/library/en-us/dnglobspec/html/dimeindex.asp-comme format de message plutot que MIME comme 
le preconise le W3C (voir http://www.w3c.org/tr/2000/note-soap-attachments-20001211). 

L'objectif est bien evidemment double : 

• reduire au maximum le surcout de poids impose par les mecanismes de serialisation ; 

• limiter le temps de traitement lie au traitement du message, aux mecanismes de serialisation/dese- 
rialisation et d' allocation memoire. 

DIME permet : 

• de separer le message XML SOAP des pieces attachees en evitant ainsi une etape de serialisation 
XML couteuse ; 

• d'integrer dans un seul message plusieurs pieces de types et de contenus differents (enregistrements 
DIME) ; 

• de scinder ces pieces en plusieurs messages binaires successifs (chunks). 
Lexemple suivant illustre l'envoi d'un fichier image par un service Web : 

using Microsoft. Web. Services. Dime; 

using Microsoft. Web. Services; 

using System. Net; 

[WebMethod] 

public void Transmetlmage( ) 

{ 

SoapContext contexteReponse = HttpSoapContext.ResponseContext; 

DimeAttachment pieceAttachee = new DimeAttachment( 
"image/gif " , TypeFormatEnum.MediaType, 
@"C:\mes images\test.gif"); 

contexteReponse. Attachments. Add (pieceAttachee) ; 
} 

La mise en oeuvre de DIME par WSE est realisee par plusieurs classes de l'espace de noms 

Web. Services. Dime : 

• DimeAttachment specifie une piece attachee DIME d'un message SOAP ; 

• DimeAttachmentCol lection est une collection de pieces attachees DIME ; 

• Di meFormatExcepti on est l'exception levee lorsque le format d'un message DIME est invalide ; 

• DimeReader permet de lire une succession d' enregistrements DIME depuis un flux ; 

• Di meRecord represente l'en-tete et les donnees d'un enregistrement DIME ; 

• Di meWri ter permet d'ecrire une succession d' enregistrements DIME dans un flux. 
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WSE et la specification WS-Routing 

WS-Routing (http://msdn.microsoft.com/library/en-us/dnglobspec/html/wsroutspecindex.asp) est une specifica- 
tion proposee par Microsoft qui definit un protocole permettant le routage des messages SOAP (chai- 
nes d'acheminement) quelle que soit la couche de transport (TCP, UDP, HTTP etc.). Le chemin aller 
(et retour) emprunte par le message est decrit directement dans Fenveloppe SOAP du message. 

La mise en ceuvre de WS-Routing par WSE se traduit par un service de routage qui peut etre imple- 
mente sur tout serveur Web ASP.NET. Ce service s'appuie sur un fichier de configuration XML 
(refferal cache) qui permet de decrire les regies de routage a appliquer en fonction des adresses des 
differents services Web (URL). 

Lobjectif est que le serveur qui heberge le service de routage devienne un point d'entree unique du 
point de vue des clients (par exemple pour l'ensemble des services Web d'une entreprise). Le service 
de routage determine ensuite precisement a qui doivent etre adressees les requetes recues et ce de 
maniere transparente pour les clients. De cette maniere, il est par exemple possible d'assurer la conti- 
nuite du service lors de la maintenance d'un serveur physique. Mais les applications de routage 
peuvent etre bien plus complexes puisque WSE permet de developper des services Web specialises 
dans le routage de messages SOAP : il est ainsi possible d'implementer des regies de routage plus 
precises, par exemple en fonction du contenu des messages ou de parametres de qualite de service 
(temps de reponse, disponibilite, etc.). 

La mise en ceuvre du service de routage est realisee en trois etapes : 

1. La premiere etape consiste a modifier le fichier web . conf i g afin d'indiquer au service quelles sont 
les requetes qui doivent faire l'objet d'un routage. Lexemple suivant permet de traiter toutes les 
requetes dont les URL contiennent servi ce*. asmx : 

<configuration> 
<system.web> 
<httpHandlers> 
<add verb="*" path="service*.asmx" 
ty pe= "Microsoft. Web. Services. Routing. Rout ingHandler , 
Microsoft. Web. Services, Vers ion=l. 0.0.0, 
Culture=neutral , 

PublicKeyToken=31bf3856ad364e35" /> 
</httpHandlers> 
</system.web> 
</configuration> 

2. La seconde etape consiste a indiquer au service F emplacement de la table de routage (refferal 
cache), d'abord en creant une nouvelle section du fichier de configuration : 

<configuration> 
<configSections> 
<section name= "microsoft. web. services" 
type=" Microsoft. Web. Services. Conf igurati on. WebServicesConfigurati on, 
Microsoft. Web. Services, Version=l. 0.0.0, Culture=neutral , 
PublicKeyToken=31bf3856ad364e35" /> 
</configSections> 
</configuration> 
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Puis en indiquant dans cette section F emplacement du fichier dans lequel est decrite la table de 
routage. Exemple : 

<configuration> 
<mi crosoft . web . servi ces> 
<referral> 

<cache name="referralCache.config" /> 
</referral> 
</mi crosoft. web. servi ces> 
</configuration> 

3. Enfin, la derniere etape consiste a decrire la table de routage dans un fichier XML dont la syntaxe 
est la suivante : 

<?xml version="1.0" ?> 

<r: referrals xmlns : r=" http://schemas.xnil soap.org/ws/2001/10/referral "> 
<r: ref> 
<r:for> 

<r:exact />|<r:prefix /> 
</r:for> 
<r:if > 
<r:ttl /> 
<r:invalidates> 

<r:rid /> 
</r:inval idates> 
</r:if> 
<r:go> 

<r:via/> 
</r:go> 
<r:refld /> 
</r:ref> 
</r: referral s> 

Description des elements WS-Referral 



Element Nombre d'occurrences Description 


<r: referrals> 


Exactement un. 


Racine du document. 


<r: ref> 


Zero ou plus. 


Specifie une instruction de routage unique pour une URL. 


<r:for> 


Exactement un par element <r:ref>. 


Specifie la portion de la requete SOAP de I'instruction de rou- 
tage. 


<r:exact> 


Exactement un element <r:exact> 
ou <r:prefix> par element <r:for>. 


Specifie ('utilisation de la casse des caracteres sur les URI. 


<r:pref ix> 


Exactement un element <r:exact> 
ou <r:prefix> par element <r:for>. 


Specifie que tout URI commencant par le prefixe fourni doit etre 
considere comme eligible a I'execution de I'instruction. 


<r:if> 


Exactement un par element <r : ref >. 


Specifie un ensemble de conditions. 


<r:ttl> 


Zero ou un par element <r:ref>. 


Specifie la duree de validite de I'instruction. 


<r: inval idates> 


Zero ou un par element <r : ref >. 


Specifie I'instruction de routage qui est invalidee lorsque I'ins- 
truction en cours est valide. 
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Description des elements WS-Referral (suite) 



Element Nombre cooccurrences Description 


<r:rid> 


Zero ou un par element 
<r:inval idates>. 


L'identifiant unique de I'instruction invalidee par I'instruction en 
cours. 


<r:go> 


Exactement un par element <r:ref>. 


Specifie la portion de reroutage de I'instruction. 


<r:via> 


Un ou plusieurs par element <r:go>. 


Specifie I'URI de routage du message SOAP. 


<r:refld> 


Exactement un par element <r:ref>. 


Specifie un identifiant unique pour I'instruction (GUID). 



.NET MyServices 

Disons-le tout de suite, le projet Hailstorm qui fut par la suite nomme .NET MyServices a ete offi- 
ciellement abandonne par Microsoft en avril 2002. Mais il est quand meme interessant d'en parler et 
cela pour deux raisons : 

• d'abord, parce qu'il s'agissait d'une des pierres angulaires de la strategic .NET qui s'appuyait 
entierement sur les services Web ; 

• ensuite, parce que les objectifs du projet et ses ambitions sont toujours d'actualite. . . 

.NET MyServices visait a developper et a proposer toute une panoplie de services Web essentiels qui 
auraient du devenir les fondations de toute application orientee Internet : depuis la gestion des 
authentifications avec Microsoft Passport jusqu'a la gestion d'une bibliotheque de documents 
personnels, en passant par celle des favoris, des preferences ou des e-mails, etc. 

Vis-a-vis des entreprises, il s'agissait dans un premier temps de fournir des briques informatiques 
fondamentales, offrant un niveau fonctionnel de securite et de disponibilite eleve et qui pouvaient 
etre rapidement mises en ceuvre. Vis-a-vis des utilisateurs du Web, il s'agissait de faciliter l'usage 
d'Internet en centralisant toutes les informations personnelles autour d'un service unique, assurant la 
confidentialite et la securite de ces informations. Dans un second temps, ce depot de donnees centra- 
lisees representait pour les entreprises une source d'informations marketing extraordinaire, meme si 
en theorie, les donnees ne pouvaient etre diffusees qu'avec le consentement de chaque utilisateur. 

Pour garantir le succes de ce projet, il fallait assurer un deploiement rapide des services et Microsoft 
s'etait lance dans la recherche d' entreprises partenaires dans tous les domaines d'activite : depuis 
American Express jusqu'a Geocities, en passant par Amazon. Mais aucune ou trop peu de ces societes 
ne voulut conclure de partenariat et Microsoft dut se resoudre a mettre un terme au projet. 

II y a assurement deux raisons qui expliquent l'echec de .NET MyServices : 

• la mefiance des utilisateurs qui auraient du confier a une seule societe la gestion de toutes leurs 
donnees personnelles ; 

• la mefiance des entreprises partenaires qui auraient du systematiquement passer par un tiers pour 
acceder aux donnees de leurs clients ou prospects. 

Dans les deux cas, Microsoft n'a pas reussi a convaincre et a obtenir le niveau de confiance neces- 
saire. Mais qui aurait pu y arriver ? Sans doute personne, car les enjeux sont bien trop importants : 

• aufhentifiez un utilisateur de maniere certaine et vous pouvez garantir un paiement. . . ; 
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• identifiez un utilisateur le plus precisement possible et vous augmentez d'autant l'efficacite de 
votre offre commerciale, de votre campagne publicitaire. . . 

Le projet .NET MyServices a done vecu. Les besoins qu'il voulait satisfaire et les problemes qu'il 
voulait resoudre demeurent. De nouvelles initiatives, plus ouvertes, avec eventuellement la participa- 
tion d' organisations reellement independantes et, eventuellement, d'agences issues des pouvoirs 
publiques (surtout lorsqu'il s'agit de garantir Fidentite des personnes physiques ou morales), 
pourraient faire 1' affaire. 
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Les implementations 
sur le poste de travail 



Dans ce chapitre, nous allons nous interesser a F implementation des services Web sur le poste de 
travail au travers de quatre produits particulierement representatifs : 

• Internet Explorer ; 

• Mozilla (ou Netscape) ; 

• Microsoft Office XP; 

• Macromedia Flash MX. 

Le service Web de Google nous a semble etre un bon exemple d' implementation puisqu'il offre a la 
fois une methode simple (doSpellingSuggestion) et une methode plus complexe a traiter (doGoogle- 
Search) (voir le chapitre 10 pour un extrait du document WSDL). 



Le service Web de Google 

L'utilisation du service Web de Google est gratuite mais soumise a quelques conditions, puisque chaque utilisa- 
teur doit en premier lieu creer un compte specifique (http://www.google.com/apis). La creation de ce compte 
permet de disposer d'une cle de licence qui doit etre ensuite utilisee dans toutes les methodes de I'API du 
service. 



Chacun des produits que nous allons presenter permet d'implementer des applications sur le poste de 
travail, capables de mettre en ceuvre une logique applicative d'agregation de services Web. 
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Le behavior Internet Explorer 

La fonction de behavior est une technologie proprietaire de Microsoft qui est apparue avec Internet 
Explorer 5.0 sous Windows. Elle permet d'ajouter des extensions DHTML a des elements HTML 
standards, c'est-a-dire d'etendre le modele objet de l'element pour lui ajouter de nouvelles fonctionna- 
lites. Ces nouvelles fonctionnalites sont alors disponibles pour les langages de script (VBScript ou 
JavaScript) et executees par le client. Un behavior peut etre defini a l'aide d'un fichier de script 
HTML (HTC) ou a l'aide d'un composant binaire DHTML (Visual C++/ATL). 

Le behavior WebService est done une extension qui s'integre dans une page HTML pour permettre a 
la page de consommer un service Web a l'aide des protocoles SOAP 1.1 et WSDL 1.1. II s'agit bien 
d'une technologie cliente qui s'appuie uniquement sur les possibilites dTnternet Explorer : 

• l'implementation, c'est-a-dire les interactions avec cet element, est codee en langage de script 
(JavaScript) ; 

• les resultats des appels de methodes sont traites par le biais d'evenements ou de fonctions de call- 
back. 

Une fonction interessante de ce behavior est la possibilite de traiter les appels de methode en 
synchrone ou en asynchrone : 

• en synchrone, l'interface est bloquee le temps de l'appel de methode et du traitement du resultat ; 

• en asynchrone, l'appel de methode est traite en multitache et l'interface est liberee. Cette fonction 
permet de construire des interfaces evoluees dans lesquelles les informations peuvent etre actuali- 
sees independamment les unes des autres. 

Le behavior WebService est encore en version beta 2 il est fourni sous forme d'un petit fichier webser- 
vi ce . htc de 51 Ko compose d'environ deux mille lignes de script. 



Compatibility Apple Mac 

Ce behavior, comme beaucoup d'autres, ne fonctionne pas sur Macintosh. 



Utilisation du behavior WebService 

Pour utiliser aisement le behavior WebService, il est d'abord necessaire de copier en local le fichier 
HTC depuis le site de Microsoft : ceci permet d'eviter des problemes lies aux controles de securite 
effectues sur les elements behavior. 



Site Microsoft (fichier HTC) 

Voir http://msdn.microsoft.com/downloads/samples/intemet/behaviors/library/webservice/webservice.htc. 



II faut ensuite l'attacher a la page HTML : 

• Le fichier HTC est mis en oeuvre en utilisant un style behavior soit a l'aide de l'attribut STYLE d'un 
element HTML, par le biais d'une feuille de style (CSS), soit par des methodes de script. L'element 
en question peut etre au choix le BODY de la page, un DIV specifique, etc. 
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• II est aussi necessaire de definir l'attribut ID qui permettra de referencer le service dans le code de 
script. 

Exemple : 

<html><head> 
<style> 

WebServiceStyle {behavior:url ( 'webservice.htc' )} 
</style></head> 
<body> 

<!-- utilisation de l'attribut style--> 

<di v id=" servicel" style="behavior:url (webservice.htc)"X/div> 

<!-- utilisation d'une definition de style--> 

<div id="service2" class="WebServiceStyle"X/div> 
</bodyX/html> 
Ou encore : 
<htmlXhead> 

<script 1 anguage="JavaScript"> 
function init()( 

servicel. style. behavior = "url ( 'webservice.htc' )" ; 

service2.addBehavior ("webservice.htc") ; 
} 

</scriptX/head> 
<body onload="init( )"> 

<div id="servicel"X/div> 

<div id="service2"X/div> 
</bodyX/html> 

II n'y a a priori aucune raison de charger plusieurs behaviors dans la meme page, puisqu'un seul suffit 
pour gerer plusieurs appels de methodes de plusieurs services Web distincts. 

Declaration du service Web 

La methode useServicetsWebServicelIRL, sFriendlyName [.oUseOptions]) du behavior permet de 
declarer le service Web que Ton souhaite utiliser : 

• Le parametre sWebServi ceURL represente le chemin du fichier WSDL du service. II peut s'agir aussi 
bien d'un fichier local que d'une URL. 

• Le parametre sFriendlyName permet d'identifier le service Web dans le code de script puisque 
plusieurs services Web peuvent etre utilises dans la meme page. 

Exemple : 

I service.useService( "http://63.210.240.215/d2s/20011205/Add.asmx7WSDL", "WSAddition") ; 
service. useService( "http://api .google.com/GoogleSearch.wsdl .com " , "WSGoogle" ) ; 

• Le dernier parametre oUseOpti ons est optionnel et permet de definir des options de declaration par 
le biais d'une occurrence d'objet useOptions, creee a partir de la methode createUseOptions. Cet 
objet permet d'indiquer au behavior si les informations d'authentification doivent etre maintenues 
pour toutes les connexions lorsque le service Web utilise le protocole SSL. 
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Exemple : 

IVar options = service. createUseOptions( ) ; 
Options. reuseConnection - true; 
service. useService( "http://63.210.240.215/d2s/20011205/Aclcl.asnix7WSDL", "WSAddition", options); 

La declaration du service peut declencher un evenement qui permet de traiter la suite des operations 
et surtout de verifier que cette etape s'est deroulee correctement. Pour declencher cet evenement, il 
suffit de declarer une fonction de callback a l'aide de la propriete onServi ceAvai 1 abl e. Cet evenement 
dispose de plusieurs proprietes : 

• Servi ceAvai 1 abl e, qui indique si le fichier WSDL a ete recupere et correctement traite ; 

• Servi ceURL, qui est l'URL du service Web ; 

• UserName, qui est l'identifiant utilise pour designer le service Web ; 

• WSDL, qui est le document XML de description du service. 
Exemple : 

function loadService( ){ 

service. onServiceAvailable = serviceReady ; 

servi ce.useService( "http://63.210.240.215/d2s/20011205/Add.asmx7WSDL", "WSAddition", options); 
} 
function serviceReady( ){ 

alertC'Le service " + event. username + " est " + (event. serviceAvailable?"0k" : "Ko")) ; 
} 

Invocation d'une methode de service Web 

La methode call Servi ce([oCall Handler,] fo, oParam) du service Web permet d'invoquer la 
methode du service Web que Ton souhaite utiliser : 

• Le parametre oCall Handler est optionnel et permet de definir une fonction de callback qui 
permettra de traiter le resultat de l'appel. 

• Le parametre f o est soit le nom de la methode exposee par le service Web, soit une occurrence 
d'objet cal 1 creee par la methode createCal 1 Opti ons et qui permet de definir precisement l'appel 
de la methode. 

• Le(s) parametre(s) oParam est (sont) le(s) parametre(s) attendu(s) par la methode du service Web. 

Le resultat de cette methode depend du mode d'invocation (voir la section « Traitement du resultat de 
l'appel ») : 

• En mode synchrone, le resultat est celui de la methode du service Web, c'est-a-dire une occurrence 
d'objet result. 

• En mode asynchrone, le resultat est un entier qui identifie l'occurrence d'appel de la methode. 

Le mode d'invocation est par defaut asynchrone mais il peut etre modifie a l'aide d'une occurrence 
d'objet cal 1 . Cet objet possede les proprietes suivantes : 

• Async, un booleen qui permet de fixer le mode d'invocation synchrone ou asynchrone de la 
methode ; 

• EndPoi nt, une URL qui determine le chemin du fichier WSDL du service Web ; 
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FuncName, le nom de la methode exposee par le service Web, cette propriete est la seule qui soit 
vraiment obligatoire ; 

Pa rams, un tableau de parametres de la methode ; 

Password, le mot de passe d'authentification de la methode ; 

PortName, le port TCP utilise par la methode ; 

SOAPHeader, un tableau d'en-tetes SOAP qui remplace celui qui est genere par le behavior ; 

UserName, le nom de l'utilisateur utilise par l'authentification de la methode. 

Exemple : 

var key = "alwmldk6bn80KJn6P" ; // cle de licence Google 
var callObj = service. createCal 1 Opti ons ( ) ; 

// Appel synchrone du service de suggestion orthographique 

service. useService( "http: //api .google.com/GoogleSearch.wsdl .com" , "WSGoogle") ; 

callObj .async = false; 

callObj .funcName = "doSpel 1 ingSuggestion" ; 

sResult = service. WSGoogle. callService(callObj , key ."Britney spirs"); 

// "Britney spirs" s'ecrit "Britney spears" 

alertC'La bonne orthographe est " + sResul t.val ue) ; 

Traitement du resultat de I'appel 

Nous avons vu que le mode d'invocation par defaut d'une methode de service Web est asynchrone et 
que le resultat de la methode cal 1 Servi ce est alors un entier qui identifie 1'occuiTence d'appel. Lorsque 
le behavior recoit la reponse du service Web, il traite cette reponse de deux manieres : 

• Si la methode cal 1 Service definit une fonction de callback, alors cette fonction est appelee et le 
resultat est passe en parametre de la fonction. 

• Sinon, le behavior appelle l'evenement onResul t et le resultat est expose par l'objet event. 

Dans les deux cas, le resultat est une occurrence d'objet resul t qui possede les proprietes suivantes : 

• Error, un booleen qui indique si le traitement de la methode a entraine des erreurs ; 

• Id, un entier qui identifie l'occurrence d'appel de la methode ; 

• Raw, un fragment XML qui contient la reponse SOAP ; 

• SOAPHeader, un tableau d'en-tetes SOAP ; 

• Val ue, la valeur retournee par la methode. 

En cas d'erreur de traitement, l'objet resul t expose egalement une occurrence de l'objet errorDetai 1 
qui possede les proprietes suivantes : 

• Code, un code d'erreur ; 

• Raw, un fragment XML qui contient la reponse SOAP ; 

• String, un message d'erreur. 
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L'exemple suivant montre comment traiter le resultat et les erreurs de resultat a l'aide d'une fonction 
de callback : 

<!D0CTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitionnal //FR"> 

<HTMLXHEAD> 

<STYLE> 

.t td{background-color:#3366cc;color:#ffffff ; font-size: -1) 

div,td{color:#000} 

a:link{color:#00c) 

a: visited {col or :#551a8b} 

a:active{color:#f00} 

.f{color:#6f6f6f;font-size:-l) 
</STYLE> 

<SCRIPT language="JavaScript"> 
var iCallld; 
var key = " alwmldk6bn80KJn6P" ; // cle de licence Google 

function loadService( ){ 
btSearch. disabled = true; 
service. onServiceAvailable = serviceReady ; 

service. useServiceC"http://api .google.com/GoogleSearch.wsdl .com" , "WSGoogle") ; 
} 
function serviceReady( ){ 

btSearch. disabled = ! event. serviceAvail able; 
} 
function doSearch( )( 

iCall Id = service. WSGoogle. cal lService(googleResult,"doGoogleSearch" , 
key .txSearch.val ue, 0, 10, false, "", false, "", "", ""); 
} 

function googleResul t(result) { 
var str = "" 
if (result. error) { 
str += "Erreur !/n" & resul t.errorDetail .code; 
str += "/n" + resul t.errorDetail .string; 
str += Vn" + resul t.errorDetail .raw; 
resul tat. innerHTML = ""; 
resul tat. innerText = str; 
} else { 
var val = resul t.val ue; 
var i = 0; 

str = "<table wi dth=100% border=0 eel 1 paddi ng=l eel lspacing=0 class='t'>" 
str += "<tr><td nowrap>Google a recherché <b>" + val .searchQuery 

+ "</b> sur le Web.</td>"; 
str += "<td align=right nowrap><b>" + val .startlndex + "-" + val.endlndex 

+ "</b> sur un total " ; 
str += (val .estimatelsExact? " ": " d'environ ") 

+ val .estimatedTotal Resul tsCount + " réponses. "; 
str += "Recherche effectuée en <b>" + val .searchTime 

+ "</b> secondes.</td></tr></table>"; 
str += "<div><p>"; 
for (i = val .startlndex - 1; i < val.endlndex ; i++ ){ 
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var valElt = val .resul tElements[i] ; 

str += "<a href-'" + valElt.URL + '">" + valElt. title + "</a><br>"; 
str += val Elt. snippet + "<br>" 
if (val El t. summary != "")( 
str += "<span class=f>Description: </span>" + val El t. summary 

+ "<br>" 
str += "<span class=f>Categorie: </span>" 
+ val El t.directoryCategory.ful IViewableName + "<br>" 
} 
str += "<font color=#008000>" + valElt.URL + " - " + val El t.cachedSize 

+ "</font>"; 
str += "</p></div>" 
} 

resul tat. innerHTML = str; 
) 
} 

</SCRIPTX/HEAD> 
<B0DY onload="loadService()"> 
<DIV id="service" style="behavior:url (webservice.htc)"> 
<I NPUT type="text" name="txSearch" size="20"> 
<I NPUT type="button" name="btSearch" val ue="Recherche Google" 

oncl ick="doSearch( )"> 
<DIV id="resultat" al ign="left"X/DIV> 
</BODYX/HTML> 

Si nous voulons maintenant utiliser la solution evenementielle, il suffit de realiser quelques modifica- 
tions mineures en commencant par l'invocation de la methode du service qui ne comprend plus de 
fonction de callback en premier parametre : 

function doSearch(){ 
iCal 1 Id = service. WSGoogle.cal 1 Service ("doGoogleSearch" , key , 
txSearch.val ue, 0, 10, false, "", false, "", "", ""); 
} 

Puis, il faut declarer l'evenement onresul t et la fonction associee : 

<DIV id="service" style="behavior:url (webservice.htc)" onresult="googleResult( )"> 

Enfin, il faut modifier notre fonction de traitement des resultats puisque 1'occuiTence d'objet result 
n'est plus passee en parametre mais est exposee par l'occurrence d'objet event : 

function googleResul t( ) { 
var str = "" 

var result = event. result; 

if((result.error)&&(iCallID==result.id)){ 

) else { 

) 
) 

Tout le reste demeure inchange. 
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Services Web en ECMAScript avec Mozilla 

La version 1 .0 de Mozilla (et done de son derive Netscape 7) introduit une nouvelle API (interface 
JavaScript) qui permet a un script d'invoquer un service Web en utilisant le protocole SOAP 1.1. La 
mise en ceuvre de cette API est proche de celle du behavior Internet Explorer, et ce a plusieurs titres : 

• II s'agit bien d'une technologie pour un client SOAP/HTTP, qui peut etre utilisee sur un poste de 
travail banalise. 

• L API introduit une couche d'abstraction suffisante pour que le developpeur n'ait pas a connaitre en 
detail le protocole SOAP, ni a manipuler des documents XML. 

• L'appel au service Web peut etre realise de maniere synchrone ou asynchrone. 

En fait, la seule difference reelle entre ces deux implementations touche a l'utilisation de WSDL. 
Contrairement a IE, la version actuelle de 1API de Mozilla ne sait pas utiliser la description WSDL 
du service Web. Le developpeur doit done « decouvrir » lui-meme le service et implementer correc- 
tement le proxy, les methodes et leurs parametres. Une nouvelle version, qui devrait combler cette 
lacune et done permettre de gagner en productivite, est en cours de developpement. 

Utilisation de I'API SOAP 

LAPI SOAP est implementee dans le navigateur et done immediatement accessible par n'importe 
quel script. Son utilisation pose neanmoins des problemes evidents de securite puisqu'une page pour- 
rait faire appel a des services a l'insu de l'utilisateur. II est done necessaire d'obtenir des droits speci- 
fiques aupres du navigateur pour pouvoir l'executer (permission "Universal BrowserRead") comme le 
montre l'exemple suivant : 

try { 

netscape. security.PrivilegeManager.enablePri vi lege ( "Universal BrowserRead") ; 
} catch (e) { 

alert(e) ; 

) 



Localisation de I'acquisition du privilege 

Le code ci-avant doit etre execute dans la fonction meme qui requiert ces privileges. 



Lobtention effective de ces droits peut etre realisee de deux manieres : 

• soit en utilisant un code JavaScript signe, ce qui sous-entend l'utilisation d'un certificat valide et 
delivre par une autorite de certification que l'utilisateur accepte ; 

• soit en executant la page et le script en local. 

Declaration du service Web 

Pour commencer, il est important de rappeler que la connaissance du document WSDL du service 
appele est obligatoire : l'API de Mozilla ne sachant pas encore exploiter la description WSDL 1.1, 
e'est au developpeur d'etudier ce document et d'en extraire les informations necessaires a la mise en 
ceuvre du client du service Web decrit. 
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Pour declarer un service Web il est necessaire de creer une nouvelle occurrence de l'objet SOAPCal 1 et 
de preciser l'URI principal du service : cette adresse est fournie par l'element service du document 
WSDL. Cet objet est au cceur des operations puisqu'il permet de parameter le service, d'encoder le 
message et de l'envoyer. 

Exemple : 

Ivar WSGoogle = new SOAPCalK); 
WSGoogle.transportURI = "http://api.google.com/search/beta2"; 

Declaration d'une methode de service Web 

L'objet SOAPCal 1 implemente l'interface ISOAPMessage qui definit la methode encode. Comme son nom 
l'indique, cette methode permet d'encoder un message SOAP, c'est-a-dire de constituer le message 
XML d'invocation d'une methode du service avec ses arguments. 

Cette methode attend les parametres suivants : 

• aversion, fixe a pour SOAP 1.1 ; 

• aMethodName, une chaine de caracteres qui est le nom de la methode invoquee (nul 1 si le message 
n'est pas de type RPC mais de type document) ; 

• ATargetObjectURI, une chaine de caracteres qui est l'espace de noms cible du service. Cet espace de 
noms est defini par l'attribut targetNamespace de l'element Definitions du document WSDL (nul 1 
si le message n'est pas de type RPC mais de type document) ; 

• AHeaderBlockCount, la taille du tableau aHeaderBlocks ; 

• AHeaderBlocks, un tableau de type ISOAPHeaderBlock (sinon null). Ce parametre permet de specifier 
des blocs d'en-tetes du message ; 

• AParameterCount, la taille du tableau aParameters ; 

• AParameters, un tableau de type ISOAPParameter (sinon nul 1). Ce parametre permet de specifier les 
arguments de la methode invoquee. 

Exemple : 

I WSGoogle. encodetO. "doSpell ingSuggestion" , "urnrGoogleSearch" , 0, 
null, parametres. length, parametres); 

Les parametres doivent etre declares un par un en creant des occurrences d'objets SOAPParameter et en 
les placant dans un tableau JavaScript qui sera passe en argument de la methode encode. Ces parametres 
sont decrits dans le document WSDL sous l'element message correspondant a la methode invoquee. 
Dans l'exemple suivant, la methode doSpel 1 ingSuggestion possede deux parametres key et phrase : 

<message name="doSpel 1 ingSuggestion"> 

<part name="key" type="xsd:string" /> 

<part name="phrase" type="xsd:string" /> 
</message> 

Chaque definition de parametre SOAPParameter doit au moins preciser deux attributs : 

• Val ue, la valeur du paramete ; 

• Name, son nom tel que defini dans le document WSDL. 
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Une methode plus rapide consiste a utiliser les parametres du constmcteur. L'exemple suivant cree 
une occurrence du parametre key et lui affecte la valeur my key : 

var parametres = new ArrayO ; 

parametres[0] = new SOAPParameter(mykey, "key" ) ; 

Invocation synchrone d'une methode de service Web 

Une fois les parametres declares et le message encode, il ne reste plus qu'a invoquer la methode, ce 
qui peut etre realise de maniere synchrone avec la methode invokeO : dans ce cas, la methode 
retourne le resultat du service Web comme contenu d'une occurrence d'objet SOAPResponse. 

La gestion des erreurs doit faire face a deux types d'incidents : 

• des problemes techniques de « bas niveau » : dans ce cas, c'est la methode elle-meme qui peut 
echouer ; 

• des erreurs d'un niveau plus fonctionnel, renvoyees par le service Web lui-meme : ces erreurs sont 
decrites par un objet SOAPFaul t, lui-meme accessible a partir de l'attiibut f aul t de Fobjet SOAPResponse. 

L'objet SOAPFaul t possede les attributs suivants : 

el ement, l'element DOM de l'erreur dans le message de reponse SOAP ; 

f aul tNamespaceURI, FURI de l'espace de noms de l'erreur ; 

faultCode, le code d'erreur ; 

faultstring, la description de l'erreur ; 

faultActor, l'acteur de l'erreur ; 

detail, l'element DOM decrivant en detail l'erreur. 
Exemple : 

try{ 

var oResult = WSGoogle.invoke( ) ; 
} catch(e) { 

alertC'Echec du service !"); 

return; 
} 
if (oResult. fault != null) 

{ 
alert(oResul t. fault. f aul tSt ring) ; 
return; 

} 

Comme nous l'avons dit, le resultat de 1' invocation de la methode de service Web est renvoye par un 
objet SOAPResponse qui implemente l'interface ISOAPMessage. II possede egalement une methode 
getParameters( ), laquelle permet de traduire les parametres de la methode de service Web en retour- 
nant un tableau JavaScript d'objets SOAPParameter. Ces objets sont done du meme type que ceux que 
nous avons utilises en entree du service. Lorsque le resultat est simple, il est done possible d'y acce- 
der en utilisant directement l'attribut val ue d'un parametre. 
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La methode getParameters( )attend les parametres suivants : 

• aDocumentStyle, qui renvoie true si l'invocation est de type document, false si elle est de 
type RPC ; 

• aCount, un objet generique JavaScript Object ( ) qui permet de recuperer le nombre de parametres 
contenus dans le tableau. 

L'exemple suivant illustre l'utilisation de la methode doSpellingSuggestion de Google en mode 
synchrone : 

function spel 1 ingSuggestiont ) { 
var parametres = new ArrayO; 
parametres[0] = new SOAPParameter(mykey , "key") ; 
parametres[l] = new SOAPParameterC'Britney spirs" , "phrase") ; 

try { 

netscape. security .Priv ilegeManager. enablePrivi lege ( "Universal Browser Read" ) ; 
} catch (e) { 

alert(e) ; 

return; 



var WSGoogle = new SOAPCalK); 

WSGoogle.transportURI = "http://api.google.com/search/beta2"; 
WSGoogle. encodetO, "doSpellingSuggestion", "urn:GoogleSearch" , 0, 
null, parametres. length, parametres); 

try { 

var oResult = WSGoogle. invokeC ) ; 
} catch(e) { 

alertC'Echec du service !"); 

return; 



if (oResult. fault != null ) { 
alert(oResul t. fault. faultSt ring) ; 
return; 



parametres = oResult. getParameters(fal se, {}) ; 
alertC'La bonne orthographe est : " + parametres[0] .value) ; 
} 

Invocation asynchrone d'une methode de service Web 

L'invocation asynchrone des methodes de services Web est realisee grace a la methode asyncln- 
voke( ) : cette methode ne retourne aucun resultat puisque celui-ci est traite par une fonction de call- 
back elle-meme passee en parametre de la methode. 

Exemple : 

WSGoogl e.async Invoke (googleResul t) ; 
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La fonction de callback doit obligatoirement posseder trois parametres : 

• reponse, une occurrence d'objet SOAPResponse qui contient le message de reponse du service ; 

• appel , une occurrence d'objet SOAPCal 1 qui contient le message d'invocation du service ; 

• erreur, un code d'erreur. 

Le dernier parametre permet de traiter les erreurs de « bas niveau » (comme les erreurs de transport) 
tandis que les erreurs retournees par le service sont decrites par un objet SOAPFaul t, lui-meme accessible 
apartirde Fattribut fault de l'objet SOAPResponse. 

Exemple : 

function googleResul t(reponse, appel .erreur) 
{ 
if (erreur != 0) { 
alertC'Echec du service"); 
return; 
} 

if (reponse. fault != null) { 
str += "Erreur !/n" & reponse. fault. faultCode; 
str += "/n" + reponse. fault. faultString; 
alert(str) ; 
return; 
} 
) 

Dans la section precedente, nous avons vu qu'il etait possible d'acceder directement a une valeur 
retournee par le service grace a l'attribut value d'un parametre SOAPParameter. Cette technique 
s'avere neanmoins inadaptee lorsque le resultat du service contient des types complexes tels que des 
tableaux. II est alors necessaire de manipuler directement le corps du message XML a partir de 
l'attribut element du parametre SOAPParameter. Evidemment, cette approche necessite une bonne 
connaissance du format du message decrit dans le document WSDL. 

L'exemple suivant illustre l'utilisation de la methode doGoogl eSearch de Google en mode asynchrone : 



I 



<!D0CTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitionnal //FR"> 

<HTMLXHEAD> 

<STYLE> 

.t td { background-col or:#3366cc; col or :#ffffff; font- size: -1} 

div.td{color:#000} 

a:link{color:#00c} 

a: visited {col or: #551a8b} 

a:acti ve{color:#f00} 

.f{color:#6f6f6f;font-size:-l} 
</STYLE> 

<SCRIPT language="JavaScript"> 
var mykey = "alwmldk6bn80KJn6P" ; // cle de licence Google 

function googl eResul t(response,cal 1 .error) 
{ 

if (error != 0) { 
alertC'Echec du service"); return; 

} 
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if (response. fault != null) { 
str += "Erreur !/n" & response. fault. faultCode; 
str += "/n" + response. fault. faul tString; 
document. getEl ementBylcK "resultatDiv") . innerHTML = ""; 
document. getElementByldt "resultatDiv") .innerText = str; 
return; 



var params = response. getParameters(false, {}) ; 
var val = params[0] .element ; 

var sQuery = val .getElementsByTagName( 

"searchQuery" ) .item(O) .fi rstChild.nodeVal ue; 
var iStartlndex = val .getElementsByTagNamet 

"start Index" ) . item(O) . f irstChild.nodeValue; 
var iEndlndex = val .getEl ementsByTagName( 

"end Index") . item(O) .fi rstChild.nodeVal ue; 
var bEstimatelsExact = val .getElementsByTagName( 

"estimate Is Exact") . i tem(O) .fi rstChild.nodeVal ue; 
var i EstimatedTotal Resul tsCount = val .getElementsByTagName( 

"estimatedTotal Resul tsCount") . item(O) . f i rstChild.nodeVal ue; 
var iSearchTime = val .getElementsByTagNamet 

"searchTime" ) .item(O) .f i rstChi ld.nodeVal ue; 
var iStartlndex = val .getElementsByTagNamet 

"start Index" ) .item(O) .f i rstChi ld.nodeVal ue; 
var iEndlndex = val .getEl ementsByTagName( 

"end Index") .item(O) .fi rstChild.nodeVal ue; 

var i = 0; 

var str = "<table width=100% border=0 eel 1 paddi ng=l eel 1 spacing=0 class='t'>"; 

str += "<tr><td nowrap>Googl e a recherché <b>" + sQuery 

+ "</b> sur le Web.</td>"; 
str += "<td align=right nowrap><b>" + iStartlndex + "-" + iEndlndex 

+ "</b> sur un total " ; 
str += (bEstimatelsExact? " ": " d'environ ") + i EstimatedTotal Resul tsCount 

+ " réponses . "; 
str += "Recherche effectuée en <b>" + iSearchTime 

+ "</b> secondes.</td></tr></table>"; 
str += "<div><p>"; 

var val El t = val .getEl ementsByTagName( "item" ) ; 
for (i = 1; 1 < valElt. length ; i++ ){ 
var valEltltem = valElt[i]; 

str += "<a href='" + val El tItem.getElementsByTagName( 
"URL").item(0).firstChild.nodeValue + '">" 
+ val El t Item. get Element sByTagName( 

"title"). item(0).firstChild.nodeValue + "</a><br>"; 
str += val El tltem. getEl ementsByTagName( 

"snippet" ). item(O) .fi rstChild.nodeVal ue + "<br>"; 
if (val El tltem. getEl ementsByTagName( "summary" ) .item(0) .fi rstChi Id != null){ 
str += "<span class=f>Description: </span>" 
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+ val EltItem.getElementsByTagName( 

"summary") . item(O) .fi rstChild.nodeVal ue + "<br>"; 
str += "<span class=f>Categorie: </span>" 
+ val EltItem.getElementsByTagName( 

"full Viewabl eName" ) .item(O) .fi rstChild.nodeVal ue + "<br>" ; 
} 

str += "<font color=#008000>" + val El tItem.getElementsByTagName( 
"URL").item(0).firstChild.nodeValue + " - " 
+ val El t I tern. get El ementsByTagName( 

"cachedSize" ) .item(O) .fi rstChild.nodeVal ue + "</font>"; 
str += "</p></div><br>"; 
} 

document. getElementByldC'resul tatDiv") . innerHTML = str; 
} 

function doSearchO ( 
var parametres = new ArrayO; 
parametres[0] = new SOAPParametertmykey , "key" ) ; 
parametres[l] = new SOAPParameter(document.getElementById( 

"txSearch" ) .val ue, "q" ) ; 
parametres[2] = new SOAPParameter(0, "start") ; 
parametres[3] = new SOAPParameterdO, "maxResul ts" ) ; 
parametres[4] = new SOAPParameter(fal se, "filter" ) ; 
parametres[5] = new SOAPParameterC" , "restrict") ; 
parametres[6] = new SOAPParameter(fal se, "safeSearch" ) ; 
parametres[7] = new SOAPParameterC" , "1 r" ) ; 
parametres[8] = new SOAPParameterC" , "ie" ) ; 
parametres[9] = new SOAPParameterC" , "oe" ) ; 

try { 

netscape. security .Privil egeManager.enabl ePri vil ege( "Uni versa! Browser Read" ) ; 
} catch (e){ 

str += "Erreur !/n" + e; 

resul tat. innerHTML = ""; 

resul tat. innerText = str; 

return; 
} 

var WSGoogle = new SOAPCalK); 

WSGoogle.transportURI = "http://api .google.com/search/beta2" ; 

WSGoogle. encode(0, "doGoogleSearch" , "urn:GoogleSearch" , 0, 
null, parametres .length, parametres); 

WSGoogle.asyncInvoketgoogl eResul t) ; 
} 

</SCRIPTX/HEAD> 
<BODY> 

<INPUT type="text" id="txSearch" size="20"> 

<I NPUT type="button" name="btSearch" 

val ue="Recherche Google" oncl ick="doSearch( ) ; "> 

<DIV id="resultatDiv" al ign="left"X/DIV> 
</BODYX/HTML> 
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Utiliser Microsoft Office XP en tant que client SOAP 

Le Web Services Toolkit pour Office XP permet d'integrer les fonctions de decouverte et d' integration 
de services Web dans toute application VBA de MS Office XP (Excel, Word et PowerPoint). La 
version 2.0 du toolkit est compatible SOAP 3.0 (1.2). 

MS Office, qui est le leader inconteste du marche des outils de bureautique, se retrouve ainsi direc- 
tement connecte aux systemes d'information des entreprises. II permet done a tout utilisateur de 
disposer dynamiquement des donnees actualisees de son entreprise et de les utiliser simplement 
dans des courriers, des tableaux ou des presentations. Les applications sont immenses, non seule- 
ment pour ce qui touche a la consultation des donnees, mais aussi pour leur mise a jour, puisque 
toute application Office pourrait egalement etre utilisee en tant qu'interface de saisie. II est par 
exemple possible d'utiliser Word comme editeur HTML Wysiwyg pour mettre a jour le contenu 
editorial d'un site intranet. 

Le Web Services Toolkit pour Office XP est un des meilleurs exemples qui soient pour demontrer 
l'efficacite des services Web et l'interet strategique qu'ils represented pour les entreprises. 

Decouverte d'un service Web 

La decouverte d'un service Web est realisee a partir de 1' editeur VBA de Office : le toolkit 
rajoute une entree Web Service Reference dans le menu Outils qui fait apparaitre une fenetre de 
recherche et de decouverte de services Web (voir figure 16-1). Deux methodes de recherche sont 
disponibles : 

• par le biais d'un serveur UDDI (par defaut, celui de Mcrosoft : http://uddi.microsoft.com/inquire), en soumet- 
tant des mots-cles et/ou des noms d'entreprises. Le caractere « % » est utilise comme caractere 
generique ; 

• en saisissant directement FURL du service Web (par exemple : http://api.google.com/GoogleSearch.wsdl). 
Une fois le service trouve, les methodes publiees sont affichees et selectionnables. Un bouton Tester 
permet meme de les invoquer pour peu que les methodes soient implementees en HTTP-GET 



HTTP-GET 

Les methodes de service Web qui implemented HTTP-GET peuvent etre invoquees par une simple URL en 
passant les arguments de methode en parametre dans I'URL. 



La selection du service et de ses methodes declenche la generation automatique du code VBA : 
e'est une demonstration « visuelle » de la puissance de l'approche de la technologie des services 
Web ! (voir figure 16-2) 
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Figure 16-1 

Recherche et decouverte d'un service Web sous Office XP. 



i.l-g «S H « - i ii ■ k£ *J rtf W r* W um«di 



jiBstHgiiwrn^wrgrairBBWi 



■cdr 



- j£& fiJUiTrinl(rtlRnTr¥lt.l(IA> 

- ££ VBW»o1e£t(Cl«seurt> 

®Fw»L(Feull) 
#3 f. :j :■■?.>.: :-. 

TrtWurklMik. 



I; 




efl iJkjI _Fflfiw ^jimyfeSe-iiJiS 
SS rfaw_Coc^e5each5cfvlra 
liS tfn H+Jli rrr it YTntrcpiy 



ftWwbet ► J» I Par ntegoi} ] 



brAarJm 1 - Ppw-sIb 



-r\ | wirn_daU»Dle£icireh 



'Ceete clssse a tie cxifa uai Web seivme tefecencfls Tuui i.o. 

'Late de creation : 1L/10/20D2 02 : S3 : 0? PH 

1 CeLLe l-1b2=e e:L ueic i. cli l e—e til. a L uu Je trlaiae Visual Ea;iu pOUC it'pl 
1 tel qu 1 il cat. cJeiini pac Utcp:/,'api.,g , ooole.cciiB/CooolcSearch.watli. 

'Pour l' ucaliaer : 

1 Bvwett* 1 nnnrr urn- vn r i nrt* ] !■ i*-n hmsr Jjur nm 

1 uliliset Acs' melJiuiiea- Iuuluic- paL la irlaaac. 

■ I>;c^iplc : 

1 Kirn ExajripleUou u Hev clsvs GoogleGeacchUerirlce 

1 debug . e t: mi E HaJnj: leVar . usid_1dQ€^ CacTie dPaae I "Eh emo i e d. ' enc re.e ,r 



liui firing I r Krnr rtiKrrvn 



'Fi.il plus J' iiiIuuihiLiuils, CLhEL-ul'.cz Tv[iei uusiipiexe^ ilnxi™ l 1 slJc tie VcSj ! 
'References Tirol 2.0. 

■Les mod 1 1 icas ions' apporcees an cade, die eette clae-ae peuvenc smrainer u 



nr-n.-:! nn^Tirj [i n lvn.F„*- r: ] nn.i vn r l nib ] r.-i . 

Private sc-jJcorjleSearcMService Xs 5oapClienG3Ci 

fnf.r C*aiiC p. HHIH. HO, Jlfl Wr.rinrj - n h.M-.p ://njn . rjmng H 
jaLe Ctiixsl. c_3ERVIi7E JIj 3Lliiij - "Gu-uy le3 cox irltSeL v n 

Crlvntc Const c_P0SlT Aa Strlrto; - "CooajlcEcaccnroct™ 



-g'i i 



Figure 16-2 

Generation automatique du code VBA du proxy. 
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Implementation du service Web 

Une fois le service Web decouvert et reference, le travail est assez simple : il faut d'abord creer une 
occurrence de la classe proxy generee par le toolkit (et prefixee par cl sws_). Exemple : 

Dim WSGoogle As New clsws_GoogleSearchService 

II ne reste plus ensuite qu'a invoquer les methodes du service, tache rendue d'autant plus facile que 
la fonction Intel 1 iSense est mise en ceuvre par l'editeur VBA. 

L' exemple suivant implemente la fonction de recherche du moteur de Google dont le resultat est 
illustre a la figure 16-3 : 



' Suppression des tags HTML 

Private Function ParseStr(strHTML As String) As String 
ParseStr = Repl ace(Replace(Repl ace(strHTML, "<br>", " 
"<b>", "") 
End Function 

' Initialisation de la feuille de resultat 
Private Sub InittaSheet As Worksheet) 

With aSheet 

.Range(.Cells(2, 1), 

.Range(.Cells(2, 1), 

End With 
End Sub 



'), "</b>", 



.CellsdOOO, 5)). Delete 
.CellsdOOO, 5)).RowHeight = 12.75 



' Methode principale 

Public Function doGoogleSearch(query As String, aSheet As Worksheet) 

Dim str As String 

Dim i As Long 

Dim row As Long 

Dim aRange As Range 

' Declaration et instanciation de la classe proxy 

Dim WSGoogle As New clsws_Googl eSearchService 
' Declaration des types utilisateur 

Dim result As struct_GoogleSearchResul t 

Dim valElt As struct_Resul tEl ement 

If (query = "") Then Exit Function 

' Appel de la methode du moteur de recherche Google 

' Le parametre Key a ete supprime et remplace par une constante dans le code 
' du proxy. 
Set result = WSGoogle. wsm_doGoogleSearch(query, 1, 10, False, "", False, 

' Mise en page des resultats contenus dans le type utilisateur result (structure) 
Call Init(aSheet) 

With aSheet 
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.Cells(2, 1). Value = "Google a cherche " & result. searchQuery & " sur le Web. 
str = result. startlndex - 1 & "-" & result. endlndex - 1 & " sur un total" 
str = str & Ilf (result. estimatelsExact, " ", " d'environ ") 

& result. estimatedTotal ResultsCount & " reponses. " 
str = str & "Recherche effectuee en " + CStr(resul t.searchTime) + " secondes. 
.Cell s(2, 3). Value = str 

Set aRange = .Range( .Cel 1 s(2, 1), .Cell s(2, 9)) 

aRange. Interior .Col or = vbBlue 

aRange. Font .Color = vbWhite 

aRange. Font .Size = aRange. Font. Size - 1 



row = 4 

If (UBound( result. result El ements) 
"Aucune reponse": Exit Function 



0) Then .Cellstrow, 1). Value 



For 1 = result. startlndex - 2 To result .endlndex - 2 

' resultEl ements As Variant est un type complexe matrice 

' qui contient des elements de type struct_Resul tEl ement 

Set valElt = result . resul tElementsti ) 

aSheet. Hyperlinks. Add aSheet.Cel 1 s(row, 1), valElt.URL, , 
. ParseStrtvalElt. title) 

.Range( .Cel 1 s(row, 1), .Cells(row, 2)). Merge True 

row = row + 1 

If (val El t. snippet <> "") Then 

.Cellstrow, 1). Value = ParseStr(val El t. snippet) 

. Ranget .Cel 1 s(row, 1), .Cells(row, 5)). Merge 

. Ranget .Cel 1 s(row, 1), .Cellstrow, 5)).WrapText = True 

row = row + 1 

End If 

If (val El t. summary <> "") Then 

.Cells(row, 1). Value = "Description: " 
.Cellstrow, 1) . Font. Color = RGB(204, 204. 204) 
.Cellstrow, 2). Value = ParseStr(val El t. summary) 
.Cellstrow + 1, 1). Value = "Categorie: " 
.Cellstrow + 1, 1) . Font. Color = RGB(204, 204, 204) 
.Cellstrow + 1, 2). Value 

**= ParseStrtval El t.di rectoryCategory .ful 1 ViewableName) 
row = row + 2 

End If 

.Cellstrow, 1). Value = valElt.URL & " - " & val El t .cachedSize 

.Cellstrow, 1) . Font .Color = RGBtO, 128, 0) 

row = row + 2 
Next 

End With 
End Function 
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Figure 16-3 

Service Web de Google sous Excel XP. 



Description detail lee du Web Services Toolkit 2.0 

Le toolkit ajoute une interface a l'editeur VBA qui permet de simplifier la recherche et la decouverte 
de services Web et de leurs methodes. Une fois le service selectionne, le travail de cette interface 
consiste dans un premier temps a ajouter au projet deux references importantes : 

• vers le parser Microsoft XML v4 (MSXML4.dll) ; 

• vers le client Microsoft SOAP Type Library 3.0 (MSSOAP30.dll). 

Le toolkit cree ensuite automatiquement plusieurs modules de classe qui peuvent etre de trois types : 

• Un proxy service Web prefixe par els sws_ (par exemple : clsws_GoogleSearchService). Ils'agitdu 
point d' entree du service et de ses methodes. 

• Des definitions de types utilisateur (structures) prefixes par struct_ (par exemple : 
struct_GoogleSearchResult). II s'agit de classes qui permettent de decrire en VBA des types 
d'objets complexes utilises par le service Web. 
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Une object factory prefixee par cl sof_Factory (par exemple : cl sof_Factory_Googl eSearchS) dont 
le role est de fournir Finterface entre les objets SOAP (un element XML) et VBA (les structures 
decrites dans le point precedent) pour les types utilisateur. 

Types complexes SOAP pris en charge par le toolkit 



Prefixe Description Type de donnees VBA 






En entree 


En sortie 


any_ 


Variables XML 


Occurrence de 
MSXML2.IXMLD0MNodeList 


Idem 


ar_ 


Matrices 


Tableau de string 


Tableau de variant 


en_ 


Enumerations 


String 


Idem 


obj_ 


Types definis par I'utilisateur 


Occurrence de classe de type utilisateur (prefixe struct) 


Idem 



II assure egalement la correspondance entre les types simples XML definis dans le schema de WSDL 
et les types de donnees VBA. 

Correspondance des types WSDL (SOAP) et VBA 



Type Soap TypeSOAPType Visual Commentaire 
Library 3.0 Basic 


AnyURI 


VT_BSTR 


String 




base64Binary 


VT_ARRAY | 
VTJJI1 


ByteO 




Boolean 


VT_B00L 


Boolean 




Byte 


VT_I2 


Integer 


Plage validee lors de la conversion. 


Date 


VT_DATE 


Date 


Heure reglee sur 00:00:00. 


DateTime 


VT_DATE 


Date 




Decimal 


VT_DECIMAL 


Variant 




Double 


VT_R8 


Double 




Duration 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


ENTITIES 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


ENTITY 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Float 


VT_R4 


Single 




Gday 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Gmonth 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


GmonthDay 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Gyear 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


GyearMonth 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 
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Correspondance des types WSDL (SOAP) et VBA (suite) 


Type Soap 


Type SOAP Type 
Library 3.0 


Visual 
Basic 


Commentaire 


ID 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


IDREF 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


IDREFS 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Int 


VT_I4 


Long 




Integer 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


Language 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Long 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


Name 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


NCName 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


negati velnteger 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


NMTOKEN 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


NMTOKENS 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


nonNegativelnteger 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


nonPositivelnteger 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


normal izedString 


VT_BSTR 


String 




NOTATION 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Positivelnteger 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


Qname 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


Short 


VT_I2 


Integer 




String 


VT_BSTR 


String 




Time 


VT_DATE 


Date 


Date reglee sur le 30 decembre 1 899. 


Token 


VT_BSTR 


String 


Aucune validation ou conversion n'a ete executee. 


UnsignedByte 


VT_UI1 


Byte 




Unsignedlnt 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


UnsignedLong 


VT_DECIMAL 


Variant 


Plage validee lors de la conversion. 


UnsignedShort 


VTJJI4 


Long 


Plage validee lors de la conversion. 



Macromedia Flash 

Macromedia Flash est un logiciel de poste de travail largement repandu sur le Web. L'interet de cette 
technologie est qu'elle permet de construire des interfaces graphiques particulierement riches (elle 
est meme consideree comme un veritable support d'expression artistique) sans se soucier des 
contraintes de compatibilite des navigateurs et des plates-formes. 
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Lorsque la version 5 de Flash est parue en 1999, on aurait pu penser que Macromedia prenait une 
longueur d'avance sur la concurrence car, alors que la technologie des services Web n'etait pas 
encore mature, Flash permettait deja de transmettre des documents XML via HTTP et de les traiter 
grace a un parser integre. Les interfaces Flash devenaient done dynamiques et l'interet pour cette 
technologie grandissant. 

Malheureusement, la derniere version MX (version 6) de Flash n'est pas aussi convaincante qu'on 
aurait pu l'esperer, en tout cas vis-a-vis des technologies de services Web : la raison tient du fait que 
pour des raisons de securite, un client Flash ne peut pas echanger de donnees, quelles qu'elles soient, 
avec un domaine qui n'est pas compatible avec le sien. En d'autres termes, si le client Flash a ete 
charge depuis le site www.siteA.com, il n'a pas le droit d'acceder aux donnees du site www.siteB.com, et 
qui dit echanger des donnees, dit en particulier consommer un service Web. Certes, cette mesure de 
precaution est fondee et du reste tous les clients, y compris Mozilla et Internet Explorer, l'appliquent. 
Mais proteger ne veut pas pour autant dire interdire car il existe des techniques permettant a un client 
d'acceder a un service Web en toute securite (voir les sections « Le behavior Internet Explorer » et 
« Utilisation de l'API SOAP » de Mozilla). Mais aucune d'entre elles n'est mise en ceuvre par Flash, 
ce qui limite ou plutot complexifie quelque peu l'implementation. 

Schema d'implementation d'un service Web 

Comme bien souvent en informatique, il existe toujours une solution pour contourner les dimcultes 
et Macromedia est parmi les premiers a expliquer comment Flash peut finalement acceder a 
n'importe quel service Web en toute securite : il suffit pour cela de creer un proxy sur le serveur. Le 
client Flash accede au proxy qui se trouve sur son propre domaine et le proxy consomme quant a lui 
le service Web distant (voir figure 16-4). 

www.siteA.com 



■' 


u 



Proxy serveur 
(+ fichier source swf) 



www.siteB.com 




Client Flash 

Figure 16-4 

Schema d'implementation d'un service Web avec Macromedia Flash MX. 
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Le developpement du proxy serveur peut etre realise de differentes manieres : 

• en utilisant la methode proposee par Macromedia, qui necessite les licences Flash MX remoting et 
Cold Fusion MX ; 

• en s'appuyant sur un des nombreux toolkits PHP, tel que le fameux NuSoap (voir: http:// 
dietrich.ganx4.com/nusoap), cette methode offre le double avantage d'etre simple et gratuite ; 

• ou encore en utilisant Microsoft .Net, Java (JSP), etc. 

En fait, toute technologie qui permet d'interroger un service Web et de retourner un resultat HTML 
ou XML au client Flash peut etre utilisee. 

Un bel exemple de realisation est fourni par Bernhard Gaul dont le site permet de visualiser 
graphiquement la meteo des aeroports du monde entier (voir : http://www11.brinkster.com/bgx/webservi- 
ces/weather.html). 
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Figure 16-5 

Exemple de client Flash interrogeant un service Web. 



Le service Web original est fourni par CapeStudio sous le nom de GlobalWeather (voir : http:// 
live.capescience.com/GlobalWeather/index.html). La methode utilisee pour permettre au client Flash d'acce- 
der au service Web est en quelque sorte une agregation de services puisque le proxy serveur est lui- 
meme un service Web (voir : http://www1 1 .brinkster.com/bgx/webservices/weatherFlash.asmx). 
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Le developpement d'un tel serveur proxy est tres rapide : 

• L' assistant de MS .Net genere automatiquement un proxy vers le service Web GlobalWeather. 

• Quelques lignes de code sont necessaires pour implementer la classe proxy et creer les methodes 
d' interrogation du service Web. Puis, les methodes sont elles-memes declarees comme etant celles 
de F interface d'un service Web : 

[WebMethod] 

public WeatherReport Get_Weather(string stationSelected){ 

GlobalWeather aGlobal Weather - new GlobalWeather( ) ; 

WeatherReport aWReport = aGlobal Weather. getWeatherReport(stationSelected) ; 

return aWeatherReport ; 
} 

Cet exemple est interessant a un autre titre, car il illustre parfaitement la capacite des technologies de 
services Web a s' adapter a tous les environnements et a toutes les plates-formes. Observons en detail 
son fonctionnement en execution : 

1. L'utilisateur saisit sa demande a partir d'un client Flash qui la traduit en une simple commande 
GET HTTP envoyee au service Web .Net. 

2. Le service Web .Net est lui-meme un proxy qui traduit cette interrogation en un message SOAP 
envoye au service Web Java GlobalWeather. 

3. Le service Web GlobalWeather traite la demande et renvoie la reponse SOAP. 

4. Le proxy .Net receptionne le message SOAP et le deserialise pour transformer le document XML 
en un objet. Mais le proxy etant lui-meme un service Web, ce meme objet est a nouveau serialise 
en XML pour etre envoye dans un message SOAP au client Flash. 

5. Le client Flash receptionne le message SOAP et peut traiter la reponse. 

Certes, ce n'est pas le chemin le plus court, et le jeu de serialisations/deserialisations peut se reveler 
lourd, mais 1' application Web decrite ci-avant n'utilise que des interfaces standardisees (les services 
Web) et son developpement est extraordinairement rapide. 

Conclusion 

Le poste de travail est une cible particulierement interessante pour les technologies de services Web. 
On peut imaginer que, dans un futur proche, un nombre important d' applications seront baties ou 
refondees a l'aide de technologies resultant de revolution et de F industrialisation de ce que nous 
avons « demontre » dans ce chapitre. 

La cible est particulierement large : 

• applications Web « grand public » ; 

• interfaces graphiques evoluees et animees ; 

• applications de gestion de contenu ; 

• applications professionnelles de gestion ; 

• ainsi que, sans doute, d'autres domaines non encore reperes a ce jour. 
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Applications Web grand pubiic 

Ce sont des applications Web a valeur ajoutee, developpees avec les toolkits de services Web embar- 
ques dans les navigateurs de derniere generation (MS IE 6, Netscape 7, Mozilla, etc.)- Avec un coiit 
de developpement tres contenu (nous en avons vu la demonstration), ces applications peuvent agre- 
ger intelligemment (statiquement et dynamiquement) des services Web de toute sorte et de toute 
origine. L'agregation intelligente des services heterogenes est un avantage competitif evident pour 
les applications Web grand public. Par ailleurs, le poste de travail peut devenir un veritable « assistant 
intelligent » qui interagit, pour le compte de l'utilisateur, avec toutes sortes de services disperses sur 
leWeb. 

Applications d'entreprise (etendue) 

L'offre MS Office XP, couplee avec l'agregation et la dissemination des services Web de l'entreprise, 
ouvre la voie a une nouvelle generation de systemes de gestion. 

La premiere caracteristique de ces nouveaux systemes est qu'ils precedent de F integration a valeur 
ajoutee des applications patrimoniales (legacy systems) plutot que de la refonte de ces applications, et 
ceci : 

• par transformation des applications patrimoniales en services Web sans changement de la logique 
et du code applicatif ; 

• puis par agregation et dissemination des services Web ainsi obtenus. 

La deuxieme caracteristique est que, a Faide de la technologie de services Web d'Office XP, il est 
possible d'effacer la frontiere entre applications bureautiques, done conviviales, toujours disponibles, 
a haute productivite, et applications d'entreprise (mainframe, client-serveur, technologie Web), pas 
toujours confortables a manier. 

Par exemple, l'interface editoriale d'une application de gestion de contenu ou de gestion documen- 
taire peut etre tout simplement MS Word, connectee avec les serveurs de validation, de stockage et de 
mise en ligne des informations et des documents. L'interface utilisateur d'une application de gestion 
peut etre le tableur MS Excel, lequel interagit avec les applications de comptabilite, de gestion des 
achats, de gestion de stock, de gestion de clientele, etc. de l'entreprise. En faisant un pas de plus, le 
graphisme evolue et F animation Flash (ou demain SVG) peuvent interagir avec les applications du 
back office. 

L'utilisateur travaille dans son environnement bureautique habituel de haute productivite, valide et 
sauvegarde en toute securite les resultats de son travail sur les serveurs de l'entreprise. En outre, il 
peut toujours travailler en mode deconnecte, par importation prealable des donnees sur son poste, et 
se synchroniser avec les serveurs d'entreprise a des moments choisis. Ces nouvelles « interfaces » 
homme/machine beneficient pour un coiit pratiquement nul des qualites exceptionnelles de confort et 
d'ergonomie des outils bureautiques professionnels. 

Avec la disponibilite des technologies de services Web, il est possible de proceder effectivement a 
une refonte, au moindre cout, non pas des applications mais du poste client et des interfaces homme/ 
machine. Cette demarche va bien au-dela de l'approche courante de F interaction par navigateur 
HTML, qui s'apparente plutot aujourd'hui a un terminal passif (certes relativement chatoyant). 
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II est maintenant possible d'envisager de nouveaux postes de travail capables d'agreger intelligem- 
ment, par le biais de nouvelles regies de gestion mises en ceuvre localement, les informations et les 
traitements des applications patrimoniales. Ces nouveaux postes clients sont riches d' intelligence 
applicative, mais ils restent legers, car ils ne necessitent aucune procedure d' installation lourde : les 
codes applicatifs peuvent etre telecharges et leur mise a jour est automatique (live-update). 

Le retour sur investissement 

L'agregation a valeur ajoutee sur le poste de travail des applications patrimoniales, exposees en tant 
que services Web, apparait comme la nouvelle frontiere des applications grand public et profession- 
nelles. Grace a la technologie des services Web, le retour sur investissement est sans commune 
mesure avec ce que Ton a pu constater dans le passe, car ces nouvelles « applications » vont permet- 
tre de conjuguer la reutilisation massive des applications patrimoniales (et done la preservation des 
investissements passes) avec la rapidite de developpement au moindre cout apportee par ces 
nouveaux outils et environnements sur le poste de travail. 
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Les technologies de services Web ont pour objectif de permettre la realisation de systemes d'informa- 
tion repartis, aptes a fonctionner de concert avec les precedentes technologies qui ont rendu possible 
l'emergence du reseau Internet et de la plupart de ses applications actuelles. 

Ces services Web font appel a un socle desormais bien etabli de specifications, a savoir SOAP, 
WSDL et UDDI dont les differentes implementations ont mis en evidence plusieurs variations dans 
1' interpretation de ces specifications. Ces variations induisent des difficultes d' interaction entre 
certaines de ces implementations. Au fur et a mesure de l'arrivee sur le marche de nouvelles imple- 
mentations, realisees a l'aide de langages de developpement toujours plus differents les uns des 
autres, ou de nouveaux systemes d' exploitation capables de prendre en charge ces technologies, ces 
difficultes sont devenues de plus en plus delicates a gerer et a prendre en compte. 

Ce qui est en cause ici, c'est F aptitude de toutes ces implementations a communiquer entre elles, et 
done, leur interoperabilite. C'est la raison pour laquelle les principaux acteurs dans le domaine de ces 
nouvelles technologies ont decide de reagir et de se donner les moyens d' identifier les sources de 
discordance de maniere a les publier dans un premier temps, puis a les prendre en compte dans les 
groupes de travail qui ceuvrent a revolution des specifications concernees. 

Cette reaction s'est d'abord materialised par la mise en place de groupes informels multilateraux 
d' acteurs majeurs disposant de plates-formes relativement repandues et souhaitant en mesurer 
I'interoperabilite avec d'autres implementations, lors de confrontations improvisees appelees 
Interoperability Rounds. 

Cependant, l'importance de cette question a pousse ces memes acteurs a aller plus loin et a decider, 
dans un second temps, de la mise en place d'une structure perenne et permanente, en charge de 
promouvoir et de definir les moyens de verifier cette interoperabilite entre des implementations 
d'origines diverses. 



Les plates-formes operationnelles 

Troisieme Partie 

Les tests d'interoperabilite SOAP 

La premiere proposition en ce sens revient a Tony Hong de XMethods qui envoya un mail sur la liste 
SOAP Builders (voir la section Ressources a la fin de ce chapitre) fin Janvier 2001, dans lequel il 
proposait la mise en place d'un laboratoire d'interoperabilite et de bancs d'essais de validation. 

A cette epoque, force etait de constater que Fexplosion soudaine du nombre d' implementations du 
protocole SOAP portait en elle les germes de possibles dysfonctionnements et incompatibilites qui, sans 
action preventive, auraient pu mettre en danger les debuts prometteurs de ces nouvelles technologies. 

En effet, les causes possibles de divergences etaient nombreuses. Parmi ces causes, citons : 

• les implementations partielles de la specification : cette situation pouvait en effet conduire a 
l'impossibilite de traiter un document par Fune des extremites de l'echange ; 

• les differences d' interpretation de certains points de la specification par les auteurs d' implementations 
SOAP; 

• le manque de completude et les non-dits dans les specifications SOAP 1 . 1 , qui laissaient effectivement 
le champ libre a des implementations heterogenes et done parfois divergentes ; 

• les difficultes dues a l'absence de prise en compte d'elements optionnels de la specification SOAP, 
notamment en matiere d'encodage des donnees ; 

• les anomalies et erreurs de codage des logiciels eux-memes. 

C'est ce constat qui a constitue l'element declencheur de la creation du groupe SOAP Builders. 

Le groupe agit comme un forum de discussion autour des problemes d' implementation et d'interope- 
rabilite pour tout ce qui touche au protocole de transport SOAP. 

Cette communaute fonctionne essentiellement en ligne, par cycles qui se terminent en general par 
une confrontation directe entre les differentes implementations. Ces differents cycles sont prepares 
lors de rencontres informelles entre les principaux intervenants. Ces rencontres se tiennent la plupart 
du temps en marge des principales manifestations, conferences et autres salons dedies aux techno- 
logies XML et services Web. Quatre cycles (rounds) ont deja eu lieu, en l'espace d'une periode de 
plus d'une annee. 

La communaute s'est dotee de differents moyens qui lui ont permis de discuter, mettre au point et 
organiser ces differentes confrontations. Parmi ces supports, nous pouvons relever : 

• la mailing-list qui constitue le lieu de convergence des acteurs de ce groupe ; 

• une specification des tests d'interoperabilite specifique a chaque cycle ; 

• un repertoire des points d'acces cote serveur pour chaque implementation participante ; 

• les liens vers les pages de presentation des resultats obtenus par chacune des implementations. 

Tous ces differents elements sont bien entendu publics et peuvent etre consultes par tous. 

D'autres initiatives, dont l'objectif etait de parvenir rapidement a une interoperabilite SOAP, ont vu 
le jour. Parmi elles, il faut citer l'idee de Dave Winer, proposee en mars 2001, d'organiser un « Inte- 
ropathon ». Cette proposition, discutee a travers la liste Interopathon (voir la section Ressources a la 
fin de ce chapitre), s'appuyait sur un plan qui devait s'etaler sur une periode de soixante jours (voir 
http://www.soapware.org/interopathonPlan). L'objectif de ce plan etait de verifier si la specification 
SOAP 1.1 devait etre rapidement remise en chantier ou non. Les tests prevus ne devaient porter que 
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sur des implementations SOAP sur HTTP. Cependant, suite a la difficulte d'obtenir un consensus 
rapide autour de ce plan, David Winer a prefere se retirer, laissant ainsi le champ libre a l'initiative 
SOAP Builders. 

SOAP Builders Round I 

Les preoccupations du debut de l'annee 2001 portaient essentiellement sur la partie « cablee » de 
SOAP et plus specialement sur les messages et l'appel de procedures distantes (le mode RPC). 

Les bancs d'essais du premier round d'observation ont ete prepares par Keith Ballinger (Microsoft), 
Tony Hong (XMethods), et Paul Kulchenko (soaplite.com) avec l'aide des membres de la liste SOAP 
Builders. 

La premiere confrontation, denommee SOAP Builders Round I, s'est produite dans les locaux 
dTBM a Raleigh Durham. Les resultats de ces premiers tests ont ete presentes lors du salon 
NetWorld+Interop qui s'est tenu a Las Vegas du 8 au 10 mai 2001. 

Les specifications de ce premier test d'interoperabilite sont publiees sur le site de XMethods a 
l'adresse http://www.xmethods.net/soapbuilders/proposal.html. Comme on peut le voir, cette premiere serie 
de tests ne necessitait pas le support de WSDL cote serveur. Le document fournit egalement la liste 
des points d'acces des differentes implementations utilisees cote serveur, ainsi que les adresses des 
resultats obtenus par les implementations cote client. 



Implementations testees 

Du cote serveur, les 26 implementations suivantes ont participe a ce test : Active State (http://www.actives- 
tate.com) - technologie PerlEx, Apache 2.1 (http://www.apache.org) - technologie Java/Servlet, Dolphin Harbor 
{http://www.dolphinharbor.org) - technologie Smalltalk/Spray, EasySoap++ (http://easysoap.sourceforge.net) - 
technologie C++, eSoapServer (http://www.embedding.net/eSOAP) - technologie C++, Frontier 7.0b26 (http:// 
frontier.userland.com) - scripting proprietaire, 4S4C1.3 (http://www.4s4c.com/4s4c) - technologie C++/COM, 
GLUE (http://www.themindelectric.com) - technologie Java, I0NA XMLBus (http://www.iona.com/products/ 
webserv-xmlbus.htm) - technologie Java, HP SOAP (http://www.hpmiddleware.com/SalSAPI.dll/SaServletEn- 
gine.class/products/hp_web_services/default.jsp) - technologie Java, Kafka XSLT (http://www.vbxml.com/ 
soapworkshop/utilities/kafka/default.asp) - technologie XSL, Microsoft ATL Server (http://msdn.microsoft.com/ 
library/default.asp?url=/library/en-us/vccore/html/vcconatlserver.asp) - technologie C++/C0M, Microsoft SOAP 
Toolkit 2.0 (http://msdn.microsoft.com/library/default.asp7urh/library/en-us/soap/htm/kit_intro_19bj.asp) - techno- 
logie Visual Basic/COM, Microsoft Framework .NET beta 2 (http://msdn.microsoft.com/netframework) - technologie 
.NET, Microsoft Framework .NET remoting (http://msdn.microsoft.com/library/default.asp7urh/library/en-us/dndo- 
tnet/html/hawkremoting.asp) - technologie .NET, OpenLink (http://www.openlinksw.com) - technologie C/C++(?), 
Phalanx (http://www.phalanxsys.com) - technologie Visual Basic, SilverStream (http://www.silverstream.com/ 
Website/app/en_US/ProductsLanding) - technologie Java, S0AP4R (http://www.jin.gr.jp/~nahi/Ruby/SOAP4R) - 
scripting Ruby, SOAP::Lite (http://www.soaplite.com) - technologie Perl, S0APx4 (http://dietrich.ganx4.com/ 
nusoap) - technologie PHP, SoapRMI (http://www.extreme.indiana.edu/xgws/xsoap) - technologie Java, SQLData 
SOAP Server (http://www.sqldata.com/Soap.htm) - technologie C++, TclSOAP (http://tclsoap.sourceforge.net/ 
SOAP-CGI.html) - technologie Tel, White Mesa SOAP RPC (http://www.whitemesa.com/wmsoapsvc_about.htm) - 
technologie C++ et Zolera SOAP Infrastructure (ZSI) (http://www.zolera.com/opensrc/zsi/zsi.htmt) - technologie 
Python. 
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Ces 26 implementations cote serveur ont ete testees par 15 implementations cote client et les resultats 
de ces tests sont references sur le site de XMethods a Fadresse suivante : http://www.xmethods.net/ilab. 
Malheureusement, une grande partie d'entre eux ne sont plus disponibles en ligne. 

II faut ici noter l'extreme diversite des implementations testees, reflet de la versatilite du protocole 
SOAP: 

• langages compiles ou a base de machine virtuelle : Java, Smalltalk, C++, Visual Basic ; 

• langages de scripting : Perl, Tel, Python, PHP, Ruby, XSL. 

Cette premiere serie de tests a consiste a realiser un ensemble d'appels RPC, pour lesquels 1' imple- 
mentation SOAP cliente invoque une methode de type « echo » accompagnee d'un parametre de type 
variable. L' implementation serveur SOAP decode l'appel et renvoie une reponse de meme type et 
valeur. Le resultat renvoye est compare a la requete initiale par le client qui statue ainsi sur la reussite 
ou l'echec du test. 

Les types de donnees utilises lors de ces tests etaient les suivants : 

chaine de caracteres ; 

nombres entiers ; 

nombres flottants ; 

structures ; 

objets temporels (« dateTime ») ; 

objets binaires (base 64) ; 

tableaux de chaines de caracteres ; 

tableaux de nombres entiers ; 

tableaux de nombres flottants ; 

tableaux de structures ; 

pas de types de retour (« void »). 

La derniere section de ce chapitre, Ressources, donne un certain nombre de pointeurs vers les resul- 
tats obtenus par les differentes implementations en lice. 

Les principales anomalies relevees lors de cette confrontation initiale, ont ete les suivantes : 

• impossibilite d' analyser la marque de polarite (BOM : Byte Order Mark) Unicode (voir http:// 
www.unicode.org/glossary/index. html#byte_order_mark) du flux de reponse emis par d'autres implemen- 
tations ; 

• impossibilite de decoder des donnees lorsque le recepteur utilise une version de la specification 
XML Schema (versions 1999, 2000 ou 2001) differente de celle utilisee par l'emetteur qui a realise 
l'encodage. II faut rappeler que la specification XML Schema n'etait pas encore stabilised au 
moment de la parution de la specification SOAP ; 

• en-tetes « SOAPAction » non entoures de guillemets comme le stipule la specification SOAP, d'ou des 
difficultes de prise en compte par les implementations qui se fondent sur la presence des guillemets ; 

• impossibilite de gerer le mecanisme de referencement id/href a l'interieur des enveloppes SOAP 
recues par certaines implementations. 



Le defi de I'interoperabilite 

Chapitre 17 

La liste complete des anomalies rencontrees par les differentes combinaisons logicielles testees est 
publiee sur le site de XMethods (voir http://www.xmethods.net/soapbuilders/interop.html). 



SOAP « rpc/encoded » vs SOAP « document/literal » 

L'un des problemes d'interoperabilite, frequemment rencontre par les developpeurs qui cherchent a mettre en 
ceuvre des services Web entre des clients et des serveurs ecrits en technologie .NET et Java, provient de I'imple- 
mentation partielle de la specification SOAP. 

En effet, la plupart des implementations SOAP ne prennent en charge que le style d'appel RPC, defini dans la 
section 7 de la specification SOAP (« Using SOAP for RPC »), conjointement avec le type d'encodage defini dans 
la section 5 de cette meme specification (« SOAP Encoding »). Cette configuration, dite « rpc/encoded », est 
notamment prise en charge par defaut par la plupart des implementations Java. Ceci n'est pas le cas du framework 
.NET qui, par defaut, prend en charge la configuration dite « document/literal ». D'autres rares implementations 
supportent egalement ce second format de message SOAP : c'est le cas de IONA XMLBus (Java) ou PocketSOAP 
(Visual Basic) par exemple. 

Fort heureusement, le framework .NET permet de modifier la nature du format de message SOAP et de passer 
d'un format « rpc/encoded » a un format « document/literal » et inversement de maniere tres simple. II suffit pour 
cela de jouer avec les directives de service ou de methode telles que [SoapRpcService], [SoapRpcMethod], 
[SoapDocumentService], [SoapDocumentMethod] ainsi que sur I'une des proprietes associees « Use=SoapBin- 
dingUse.Encoded » ou « Use=SoapBindingUse. Literal » (voir .NET Framework Developer's Guide : « Customizing 
SOAP Messages » a http://msdn.microsoft.com/library/default.asp7urh/library/en-us/cpguide/html/cpconcustomi- 
zingsoapinaspnetwebserviceswebserviceclients. asp) . 

L'arrivee d'implementations completes, qui prennent en charge les deux formats de message SOAP, associee a la 
prise en compte de cette subtilite dans la specification WSDL, a permis de reduire cette source de divergence 
entre implementations d'origines diverses. 



SOAP Builders Round II 

La seconde confrontation, denommee SOAP Builders Round II, est preparee des la fin du salon 
NetWorld+Interop de Las Vegas. Celle-ci voit les efforts des intervenants se porter sur les problemes 
d'encodage et d' utilisation des en-tetes SOAP. 

Cette confrontation se poursuit a l'heure actuelle. Elle est entierement pratiquee en ligne et les resul- 
tats sont publies au fur et a mesure de Favancement des tests et centralises sur le site de White Mesa 
Software (http://www.whitemesa.com/interop.htm). Les resultats de 37 implementations cote serveur et 
23 implementations cote client sont disponibles a ce jour, toutes categories de tests confondues. 

Ann de faciliter le suivi des evenements durant cette confrontation (inscription de nouveaux points 
d'acces cote serveur, publication de nouveaux resultats cote client, etc.), Simon Fell (PocketSOAP) a 
meme ete jusqu'a developper un service Web d'enregistrement et de notification (http://www.pocket- 
soap.com/registration). Ce service est accessible en ligne sur le site de SOAPClient (http://www.soap- 
ciient.com/interop/simonregistry.htmi). 

Les tests pratiques durant cette confrontation ont fait Fobjet d'un classement en trois categories appe- 
lees groupes A (ou base), B et C : 

• groupe A : reprise des tests de type « echo » de la premiere rencontre SOAP Builders Round I, 
agrementee de tests equivalents sur des types de donnees non pris en charge precedemment ; 
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groupe B : tests d'appels de type RPC avec utilisation de parametres multiples en entree et en 
sortie et utilisation de types de donnees complexes ; 

groupe C : tests de prise en compte des en-tetes SOAP et utilisation des attributs actor et mustUn- 
derstand. 



Implementations testees a ce jour 

Aujourd'hui, 37 implementations cote serveur et 23 implementations cote client publient leurs points d'acces et les 
resultats obtenus. Certaines combinaisons ne sont pas disponibles du fait de I'arrivee plus tardive de quelques 
implementations dans la communaute. 

Du cote serveur, on peut noter les produits suivants : 4s4c 1 .3 et 2.0 (http://soap.4s4c.com), Apache Axis et 
SOAP 2.2 (http://xml.apache.org), Microsoft ASP.NET, .NET Remoting, SOAP Toolkit 2.0 et 3.0 (http://mssoapinte- 
rop.org), Cape Clear CapeConnect (http://interop.capeclear.com), Delphi SOAP (http://soap-server.borland.com/ 
WebServices), EasySoap++ (http://easysoap.sourceforge.net), eSOAP (http://www.embedding.net/eSOAP), 
gSOAP (http://www.cs.fsu.edu/~engelen/soap.htmt), Frontier (http://frontier.userland.com), Glue (http:// 
www.themindelectric.com), Hewlett-Packard SOAP (http://soap.bluestone.com/hpws), IONA XMLBus (http://inte- 
rop.xmlbus.com:7002), Kafka XSLT SOAP (http://www.thoughtpost.com/content/kafka.aspx), kSOAP (http:// 
ksoap.enhydra.org), NuSOAP (http://dietrich.ganx4.com/nusoap), NuWave Technologies (http://www.nuwave- 
tech.com), OpenLink Virtuoso (http://www.openlinksw.com), PEAR SOAP (http://caraveo.com/soap_interop), 
Phalanx (http://www.phaianxsys.com), SilverStream (http://www.silverstream.com), SIM (http://www.simdb.com), 
SOAP4R (http://www.jin.gr.jp/~nahi/Ruby/SOAP4R), SOAPlite (http://www.soapiite.com), Spheon JSOAP (http:// 
soap.fmui.de), Spray 2001 (http://www.dolphinharbor.org), SQLData SOAP Server (http://www.sqldata.com/ 
Soap.htm), Sun Microsystems (http://java.sun.com/wsinterop/sb/index.html), Cincom VisualWorks Opentalk- 
Soap 1 .0 (http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki), Systinet WASP Advanced 4.0 et WASP for 
C++ 4.0 (http://soap.systinet.net/interop), webMethods Integration Server (http://www.webmethods.com) et White 
Mesa SOAP Server (http://www.whitemesa.com). 

Cote client, les implementations suivantes sont utilisees : Apache Axis et SOAP 2.3 (http://xml.apache.org), Micro- 
soft ASP.NET (http://mssoapinterop.org), EasySoap++ (http://easysoap.sourceforge.net), eSOAP (http:// 
www.embedding.net/eSOAP), gSOAP (http://www.cs.fsu.edu/~engelen/soap.html), Glue (http://www.themindelec- 
tric.com), Hewlett-Packard SOAP (http://soap.bluestone.com/hpws), IONA XMLBus (http://inte- 
rop.xmlbus.com:7002), kSOAP (http://ksoap.enhydra.org), OpenLink Virtuoso (http://www.openlinksw.com), PEAR 
SOAP (http://caraveo.com/soap_interop), PocketSOAP 1.1 (http://www.pocketsoap.com/pocketsoap), SILAB/ 
TclSOAP (http://tclsoap.sourceforge.net), SIM (http://www.simdb.com), SOAP4R (http://www.jin.gr.jp/~nahi/Ruby/ 
SOAP4R), Spheon JSOAP (http://soap.fmui.de), Spray (http://www.dolphinharbor.org), SQLData(Mfp:// 
www.sqldata.com/Soap.htm), Cincom VisualWorks OpentalkSoap 1 .0 (http://www.cincomsmalltalk.com:8080/ 
CincomSmalltalkWiki), Systinet WASP Advanced 4.0 et WASP for C++ 4.0 (http://soap.systinet.net/interop), White 
Mesa 2.7 (http://www.whitemesa.com) et Wingfoot 1 .0 (http://www.wingfoot.com). 



Les objectifs particuliers poursuivis lors de cette nouvelle campagne de tests sont : 

• 1' utilisation d' implementations qui repondent a la specification SOAP 1.1; 

• la conformite des enveloppes (cotes client et serveur) a un document WSDL predefini ; 

• la mise en ceuvre de l'encodage tel que specifie dans la section 5 de la specification SOAP. 

Cette seconde confrontation ne necessite pas encore Futilisation de la specification WSDL. Les 
documents WSDL proposes le sont a titre documentaire et peuvent etre publies par les differentes 
implementations. 
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Comme nous Favons vu, ce cycle se poursuit encore a l'heure actuelle et de nouvelles implementa- 
tions apparaissent pour se confronter aux autres : par exemple, Fred Hartman a publie en juin 2002 
les points d'acces de 1' implementation du serveur webMethods Integration Server version 4.6 
(Service Pack 1). D' autres resultats obtenus par de nouvelles versions d'anciennes implementations 
sont aussi publies regulierement, ainsi que des changements de points d'acces. 

Les tests d'interoperabilite WSDL (et complements SOAP) 
SOAP Builders Round III 

La troisieme confrontation, SOAP Builders Round HI, est dediee a la maniere dont la specification 
WSDL est utilisee dans les differentes implementations. En effet, peu apres F apparition du protocole 
SOAP, la necessite de decrire les services Web echanges etait devenue evidente et les principaux 
auteurs de SOAP s'attelerent a la tache. 

Cette troisieme confrontation, organisee dans les locaux de IONA Technologies avec la participation 
de Microsoft, s'est tenue les 27 et 28 fevrier 2002 a Waltham dans l'etat du Massachusetts. 

Les principaux objectifs de cette confrontation etaient, pour chacune des implementations, les 
suivants : 

• generer les fichiers WSDL corrects en fonction de differents scenarios et etre en mesure d'utiliser 
les fichiers generes par les autres implementations ; 

• consommer et reutiliser des fichiers WSDL imposes. 

Le detail des differents tests pratiques est publie sur le site de IONA (http://www.xmlbus.com/interop/ 
WSDLInterop-01 18.htm). Le decoupage en trois sous-groupes de tests D, E et F y est egalement presente. 



Implementations testees 

Les 18 implementations suivantes ont participe a cette troisieme confrontation (pour plus de details, se reporter 
a http://www.xmlbus.com/interop/Round_lll_attendees.xls) : Altova (XML Spy) (http://www.xmispy.com) - techno- 
logie C/C++(?), BEA (http://www.bea.com) - technologie Java, Cape Clear (http://www.capeclear.com) - techno- 
logie Java, Dolphin Harbor (http://www.dolphinharbor.org) - technologie Smalltalk/Spray, IONA XMLBus (http:// 
www.iona.com) - technologie Java, IBM/Apache (http://www.ibm.com) - technologie Java, Macromedia (http:// 
www.macromedia.com) - technologie Java, Microsoft (http://www.microsoft.com) - technologie C++/COM/.NET, 
Mindreef (http://www.mindreef.com) - technologie C/C++(?), Oracle (http://www.oracle.com) - technologie Java, 
Phalanx (http://www.phalanxsys.com) - technologie Visual Basic, PocketSOAP (http://www.pocketsoap.com) - 
technologie C++/COM, Rogue Wave (http://www.roguewave.com) - technologie C++, Systinet (http://www.sysH- 
net.com) - technologie Java, The Mind Electric (http://www.themindelectric.com) - technologie Java, White Mesa 
(Lectrosonics) (http://www.whitemesa.com) - technologie C++, XMethods (http://www.xmethods.com) - technologie 
PHP(?) et Zolera Systems (http://www.zolera.com) - technologie Python. 



Les resultats des tests obtenus par chaque implementation sont publies sur les sites respectifs des 
editeurs. Quelques liens sont references a la fin du chapitre, dans la section Ressources). 

Le site de White Mesa Software centralise l'ensemble des elements (tests, resultats, points d'acces) 
associes a cette troisieme confrontation (http://www.whitemesa.net/r3/interop3.html). 
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SOAP Builders Round IV 

Une quatrieme confrontation, SOAP Builders Round IV, a ete mise en place et une reunion pleniere 
s'est d'ores et deja tenue dans les locaux des laboratoires d'IBM a San Jose, les 3 et 4 juin 2002. 

D'apres la premiere version des objectifs poursuivis (roadmap), publies a Tissue de cette reunion 
preparatoire, des problemes aussi divers que la gestion des erreurs, Fauthentification, Finteroperabi- 
lite des schemas XML, les pieces jointes SOAP (SwA : SOAP with Attachments), la gestion de 
fichiers de type DataSet ou la gestion de collections devaient figurer au menu de cette confrontation. 

Finalement, ces differents types de tests ont ete regroupes en quatre categories : 

• groupe G : tests d'interoperabilite des implementations sur les pieces jointes SOAP SwA (SOAP 
with Attachments) et DIME (Direct Internet Message Encapsulation) en styles « rpc/encoded » et 
« document/literal » ; 

• groupe H : tests de gestion des erreurs en styles « rpc/encoded » et « document/literal » ; 

• groupe I : tests WSDL/XSD. 

Les tests initialement prevus, mais finalement non pris en compte dans cette quatrieme confrontation, 
ont ete reportes aux confrontations suivantes. La decision a ete prise lors de la teleconference de 
lancement (kick-off) de la confrontation qui s'est tenue le 10 septembre 2002 : les sujets Session, 
DataSet et Collection/Map sont reportes a la cinquieme confrontation. Le traitement de Fauthentifi- 
cation HTTP est finalement considere comme hors sujet. 

Une partie des tests a deja ete realisee par certains des intervenants et les resultats sont publies sur le 
site de White Mesa Software (voir Fadresse ci-apres). 

Le site de White Mesa Software centralise Fensemble des elements (tests, resultats, points d'acces) 
associes a cette quatrieme confrontation (http://www.whitemesa.net/r4/interop4.html). 

SOAP Builders Round V 

Une cinquieme confrontation, SOAP Builders Round V, est en preparation et une reunion pleniere 
(Face-to-Face Meeting) s'est d'ores et deja tenue dans les locaux de Sun Microsystems a Burlington 
(Massachussets), les 8 et 9 octobre 2002. 

Les societes representees lors de cette reunion etaient : BEA, Computer Associates, IBM, Lectroso- 
nics (White Mesa), Macromedia, Microsoft, Mindreef, OpenLink, Oracle, Sonic Software, Sun 
Microsystems, Systinet et webMethods. 

A Fissue de cette reunion, six groupes de tests ont ete retenus : 

• groupe 5.1 : reprise des tests de base de type « echo » des precedentes confrontations, augmentee 
de la prise en compte des types « built-in » de la specification XML Schema non couverts par les 
tests anterieurs ; 

• groupe 5.2 : utilisation de Fattribut xsi :type dans les messages SOAP ; 

• groupe 5.3 : tests de messagerie SOAP asynchrone ; 

• groupe 5.4 : gestion des erreurs HTTP ; 

• groupe 5.5 : extension des types composes dans les schemas WSDL ; 

• groupe 5.6 : intermediaires SOAP (routage). 
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Ces tests se derouleront lors de la prochaine reunion de preparation qui se tiendra fin fevrier ou debut 
mars 2003 dans les locaux de Microsoft a Redmond. Une autre reunion a ete proposee par 
webMethods : celle-ci se deroulerait en juin 2003 dans les locaux de webMethods a Fairfax (Virginie). 

Le site de Sun Microsystems centralise l'ensemble des elements associes a la preparation de cette 
cinquieme confrontation (http://java.sun.com/wsinterop/sb/r5). Les minutes de la derniere reunion sont 
notamment accessibles sur ce site (http://java.sun.com/wsinterop/sb/r5/notes.html). 

Un nouveau site Web, SOAPBuilders.org, a ete recemment mis en ligne par Glen Daniels de Macro- 
media (http://www.soapbuilders.org). Ce site devrait devenir le point d'entree vers l'ensemble des sites de 
ressources dissemines sur le reseau Internet. 



Les tests d'interoperabilite UDDI 



La premiere proposition de tests d'interoperabilite revient a Anne Thomas Manes de Systinet qui, 
dans un mail envoye sur la liste UDDI Builders (voir la section Ressources a la fin de ce chapitre) en 
fevrier 2002, proposait egalement la mise en place d'un laboratoire d'interoperabilite et de bancs 
d'essais de validation, a l'image de ce qui avait ete fait par Tony Hong de XMethods dans le cadre de 
la communaute SOAP Builders. 

Anne Thomas Manes propose cette activite de tests « aux entreprises qui developpent des serveurs 
d'annuaires UDDI et des librairies clientes ». Ces tests doivent permettre de valider des « clients 
UDDI par rapport a des serveurs UDDI qui sont differents de ceux pour lesquels ils ont ete 
developpes ». 

La societe Systinet propose, a l'adresse http://soap.systinet.net/interop/uddi, un banc d'essai UDDI. Ce 
banc d'essai est egalement decompose en plusieurs cycles (rounds) de tests, eux-memes classes en 
groupes. Pour l'instant, deux cycles ont ete definis : 

• le cycle comprend les tests les plus simples, classes en cinq groupes, et est destine a verifier que 
les serveurs et les clients UDDI communiquent sans erreurs (http://soap.systinet.net/interop/uddi/rounds/ 
roundO/index.html) ; 

• le cycle 1 comporte les tests de base, classes en dix groupes, et a pour objectif de verifier la bonne 
utilisation de l'ensemble des structures et caracteristiques UDDI (http://soap.systinet.net/interop/uddi/ 
rounds/roundl /index, html) . 

La societe Systinet a mis en place differents moyens qui vont permettre aux membres de cette 
communaute de discuter, mettre au point et organiser ces differentes confrontations. Parmi ces 
supports, nous pouvons noter : 

• la mailing-list qui constitue le lieu de convergence des acteurs de ce groupe ; 

• une specification des tests d'interoperabilite specifique a chaque cycle. 
Chaque participant doit fournir : 

• un repertoire des points d'acces cote serveur pour chaque implementation participante ; 

• une page de presentation des resultats obtenus par chacune des implementations. 
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Pour Finstant, cette initiative ne semble pas rencontrer d'echo. II est vrai que Ton ne voit apparaitre 
des implementations d'annuaires UDDI prives que depuis peu. Systinet propose des points d'acces 
pour deux de ses produits (http://soap.systinet.net/interop/uddi/productList.html) : 

• WASP UDDI 3.1 Standard ; 

• WASP UDDI 3.0 Enterprise. 

Les tests d'interoperabilite globaux 

Tres recemment, une nouvelle forme de tests d'interoperabilite est apparue. II s'agit de tests qui 
simulent le fonctionnement d'une application complete, plus proche de la realite rencontree sur le 
terrain par les entreprises (in the real world comme disent parfois les Anglo-saxons). 

Une premiere experience a ete mise en ceuvre dernierement, dont les resultats ont fait Fobjet d'une 
demonstration lors de la conference SIGS/101 XML Web Services One, qui s'est tenue du 4 au 7 juin 
2002 a San Jose en Californie (http://www.xmlconference.com/sanjose/index.asp). 

Encore une fois, c'est la societe XMethods de Tony Hong qui s'est chargee de la logistique de cette 
operation. L' ensemble des ressources utilisees lors de cette demonstration sont regroupees sur une 
page dediee du site de XMethods (http://www.xmethods.net/idemo). 

Cette application, denommee « idemo », met en jeu plusieurs acteurs qui interagissent dans le cadre 
d'une operation commerciale : un client, un fournisseur, un entrepot et un etablissement de credit. 
Cette demonstration met en ceuvre 1' ensemble de la pile protocolaire SOAP, WSDL et UDDI. 

Des societes telles que IBM, IONA Technologies, Microsoft et The Mind Electric ont implemente 
cette demonstration et ont participe a sa presentation. 

Cependant, F amelioration tres rapide des conditions de l'interoperabilite entre les differentes realisa- 
tions de ces editeurs de logiciels, ainsi qu' entre les differentes specifications utilisees dans ces logi- 
ciels, a fait naitre le besoin de placer la barre plus haut et de placer la problematique de l'interopera- 
bilite au niveau qui convient : celui d'une nouvelle autorite Internet en charge exclusive de ce 
controle de coherence devenu vital pour la nouvelle generation d'lntemet. 

Le consortium industriel WS-I 

L' organisation WS-I (Web Services Interoperability Organization) a ete creee le 6 fevrier 2002 (voir 
l'annonce Microsoft : http://www.microsoft.com/presspass/press/2002/feb02/02-06lnteropOrgPR.asp), sur 
l'initiative dTBM et de Microsoft. 

Objectif de I'organisation 

Cette organisation s'est donnee comme objectif de promouvoir l'interoperabilite des services Web 
entre les plates-formes, les applications et les langages de programmation. Elle repondra aux besoins 
des clients en fournissant des conseils, des recommandations et des outils de support destines a 
produire des services Web interoperables. 
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Membres fondateurs 

Aux cotes d'IBM et de Microsoft, a I'origine de cette initiative, les autres fondateurs sont : Accenture, BEA Systems, 
Fujitsu, Hewlett-Packard, Intel, Oracle et SAP. 

Des cette annonce, llnitiative est supportee par un grand nombre d'entreprises : Akamai Technologies, Autodesk, 
Borland, Business Objects, Cape Clear Software, Commerce One, CommerceQuest, Compaq, Corechange, 
Corillian, Daimler/Chrysler, Dassault Systemes, J.D. Edwards, Epicentric, Epicor Software, ESRI, FileNET, 
Flamenco Networks, Ford Motor, FrontRange Solutions, Grand Central Networks, Groove Networks, IONA, 
Jamcracker, Kana, Loudcloud, Macromedia, McAfee.com, Onyx Software, Peregrine Systems, Pivotal, Plumtree 
Software, POSC.org, Qwest Communications, Rational Software, RealNames, Reed Elsevier, Reuters, Sabre 
Holdings, SAS Institute, Sybase, Toshiba TEC, United Airlines, Versata, VeriSign et webMethods. 



Afin de verifier cette interoperabilite entre implementations, Forganisation WS-I fournira un ensem- 
ble d'outils de test et de verification de la conformite de ces implementations par rapport aux specifi- 
cations de base qui regissent les technologies de services Web : XML, SOAP, WSDL et UDDI. 

De meme, Forganisation WS-I suivra revolution des specifications et des standards dans le domaine 
des services Web et dressera une roadmap architecturale qui etablira les fonctionnalites qui devront 
etre couvertes par de futures specifications. L' organisation suivra ces evolutions et adaptera en conse- 
quence ses outils de controle. 

Simultanement a Fannonce de sa creation, Forganisation WS-I s'est dotee d'un site Internet de refe- 
rence (http://www.ws-i.org). 

L' organisation n'a pas vocation a emettre des specifications, des standards ou des normes. Son role 
consiste plutot a s' assurer de la coherence et de la bonne utilisation entre les productions, dans ces 
differents domaines, des organismes existants tels que le W3C, F OASIS et FIETF. II n'est pas non 
plus dans les intentions de Forganisation WS-I d'emettre un certificat de compatibilite du style 
« compatible WS-I », similaire a F etiquette « compatible J2EE » decernee par Sun Microsystems 
aux implementations Java qui passent la batterie de tests de compatibilite associee. 



Une tentative de contournement du W3C ? 

D'aucuns ont vu, a travers cet acte de creation d'une nouvelle entite de regulation du monde Internet, la volonte de 
certains groupes de faire pression sur le W3C, pour accelerer ses travaux relatifs a la standardisation des techno- 
logies de services Web, voire une tentative de supplanter le W3C dans ce domaine. 

En effet, certains acteurs de ce monde technologique, qui se trouvent vraisemblablement parmi les initiateurs, 
considered que les travaux du W3C avancent trap lentement, voire que les ressources de cet organisme sont 
detournees au profit d'autres activites comme notamment tout ce qui touche a la notion de « Web semantique » 
{semantic Web) : voir a ce sujet la section du site du W3C dediee a ce domaine a I'adresse http://www.w3.org/ 
2001 /swei le portail SemanticWeb.org a I'adresse http://www.semanticweb.org. 

On peut aussi rappeler, dans ce contexte, la publication d'un document polemique, sous forme d'une lettre au Pere 
Noel, redige en decembre dernier par Tim Ewald et Martin Gudgin de DevelopMentor et dont le principal message 
etait : « Cher Pere Noel, tout ce que nous voulons pour Noel est un groupe de travail WSDL » (http://www.xml.com/ 
pub/a/200 1/12/1 9/wsdlwg. html} . 
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Organisation et groupes de travail 



Le consortium WS-I a publie son organisation operationnelle des le 18 avril 2002, sous la forme de 
groupes de travail (annonce : http://www.ws-i.org/docs/20020418wsipr.pdf). A la date ou nous ecrivons ces 
lignes, la communaute de societes qui supportent l'organisation compte deja cent membres. 



Nouveaux membres supporters 

La creation du consortium WS-I a rapidement suscite un vif interet parmi les acteurs de ces nouvelles technolo- 
gies, malgre un debut de polemique autour de I'absence de Sun Microsystems dans le groupe des fondateurs de 
l'organisation. 

A ces premiers fervents adeptes de la premiere heure se sont ajoutees de nombreuses entreprises et parmi celles- 
ci : 101 communications, Actional, Agentis Software, Altova, Approva, Ascential Software, AT&T, Avinon, Bang 
Networks, Bowstreet, ContentGuard, Corel, Cyclone Commerce, Discrete Objects, E2open, Fox Island Partners, 
FullTilt Solutions, Geac Computer, HighJump Software, Hitachi, Hummingbird, iWay Software, Mediapps, Mercator 
Software, Metapa, Metaphorex, Micro Focus International, Mogul Technology, move3d Technology Design Consul- 
ting, NEON Systems, netlQ, Office of e-Envoy, Parasoft, Partnerware, Portera Systems, Procter & Gamble, 
Quovadx, SilverStream Software, Software AG, Sonic Software, Systinet, Talking Blocks, Tata Consultancy Services, 
TIBCO Software, Tryllian, Unisys, Versata, Vinsurance, Visuale, Vitria et WRQ. 



Trois groupes de travail initiaux sont done crees : 

• Profil de base des services Web : ce groupe a pour mission d'etablir un ensemble de specifications 
(dont XML Schema, SOAP, WSDL et UDDI) qui constituent les fondations du developpement des 
services Web. Le groupe doit formuler les recommandations d'usage des specifications qui composent 
le profil de base. 

• Applications de reference : le groupe doit produire des applications de reference de services Web 
de base. Ces applications permettront d'illustrer les meilleures manieres de faire (best practices) 
en termes de developpement et d' implementation. Elles seront realisees en utilisant differents 
langages et a l'aide de differents environnements de developpement. 

• Systemes de tests et developpement d'outils : ce groupe, dont la vocation est de developper un 
ensemble de tests de verification de la conformite d'une implementation avec les specifications du 
profil de base et les recommandations emises par le premier groupe, doit permettre de disposer des 
moyens de s' assurer que l'objectif d'interoperabilite de services Web entre plates-formes, langages 
de programmation et applications est bien atteint. 

Introduction du concept de profil 

Ces groupes de travail ont maintenant debute leur activite. Un premier document definit la notion 
de profil introduite lors de la precedente annonce de l'organisation. Celui-ci est disponible sur le 
site de WS-I a l'adresse http://www.ws-i.org/docs/WS-l_Profiles.pdf. 

Definition du profil 

Ce document fait le point sur les specifications actuelles introduites dans le domaine des services 
Web. Celles-ci sont en faible nombre pour F instant : 

• SOAP 1.1; 

• WSDL 1.1 ; 
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• UDDI2.0; 

• XML Schema 1.0. 

Ce premier noyau de standards est susceptible d'etre complete par d'autres specifications et standards 
du fait des nombreuses fonctionnalites qui ne sont pas encore couvertes, parmi lesquelles Forganisation 
identifie les suivantes : 

l'extensibilite des messages ; 

Fattachement de pieces binaires ; 

le routage des messages ; 

la correlation de messages ; 

Facheminement garanti des messages ; 

les signatures digitales ; 

le chiffrement de documents XML ; 

la gestion de transactions ; 

les flux de processus ; 

F inspection de services ; 

la decouverte de services. 

Cette liste de fonctionnalites avait deja fait l'objet d'une precedente publication dans un document 
commun (Position Paper) produit par IBM et Microsoft lors de la reunion de l'atelier sur les services 
Web (Workshop on Web Services) organise par le W3C, les 1 1 et 12 avril 2001 a San Jose en Californie : 
voir http://www.w3.org/2001/03/WSWS-popa/paper51. 

La notion de profil permet done de definir un ensemble de specifications, nommement designees et 
dont la version est explicitement precisee. Ceci permet de manier ces specifications a travers un 
niveau de granularite plus important et mieux adapte a Fetude de I'interoperabilite. Lorganisation 
verifiera la compatibilite au niveau unitaire d'une specification et au niveau d'un profil complet. 

La definition d'un profil comportera egalement des documents de conventions et de recommanda- 
tions d'usage, destines a lever les ambiguites detectees dans Fetude des specifications rattachees au 
profil. De la meme maniere, ces conventions et recommandations s'appliqueront a un niveau unitaire 
ou a F ensemble des specifications du profil. Ces elements feront l'objet d'une communication aux 
differentes instances de standardisation et normalisation qui les controlent et Forganisation suivra les 
reactions et evolutions de ces organismes. 

Le premier profil defini par Forganisation (WS-I Basic) designe les specifications suivantes : 

• XML Schema 1.0; 

• SOAP 1.1; 

• WSDL1.1 ; 

• UDDI2.0. 

Les conventions et recommandations d'usage associees a ce profil seront developpees et publiees 
ulterieurement par les differents groupes de travail du WS-I. 

Le WS-I prevoit de mettre a disposition un premier ensemble d'outils pour fin 2002. 
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Version initiale du profil de base 

Une premiere version de travail (Working Draft) du profil de base a ete rendue publique, le 29 octobre 
2002, par le groupe de travail en charge de cette definition, lors de la conference Gartner Group 
Application Integration and Web Services de Chicago (voir annonce : http://www.ws-i.org/docs/ 
20021029wsipr.doc). 

La version 1.0 de ce document est accessible a l'adresse http://www.ws-i.org/Profiles/Basic/2002-10/Basic- 
Profile-1.0-WGD.pdf. La version definitive doit etre publiee au debut de l'annee 2003. Les aspects 
suivants sont explores : 

• la messagerie ; 

• la description d'un service ; 

• la decouverte d'un service ; 

• la securite. 

Ce document definit un ensemble de regies (requirements) a respecter et s'appuie sur le vocabulaire 
tres largement utilise de la RFC2119 (Key words for use in RFCs to Indicate Requirement Levels a 
l'adresse http://www.ietf.org/rfc/rfc2119.txf) de 1'IETF. Les mots-cles MUST, MUST NOT, REQUIRED, 
SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY et OPTIONAL sont 
done largement utilises pour decrire ces regies. 

Les specifications referencees pour definir les regies de la messagerie sont : 

Simple Object Access Protocol (SOAP) 1.1 : http://www.w3.org/TR/SOAP ; 

Extensible Markup Language (XML) 1.0 (Second Edition) : http://www.w3.org/TR/REC-xml ; 

RFC2616: Hypertext Transfer Protocol -- HTTP/1.1 : http://www.ietf.org/rfc/rfc2616.txt ; 

RFC2965: HTTP State Management Mechanism : http://www.ietf.org/rfc/rfc2965.txt. 
Les regies pour la description d'un service sont regies par : 

Web Services Description Language (WSDL) 1.1 : http://www.w3.org/TR/wsdl ; 

XML Schema Part 1: Structures : http://www.w3.org/TR/xmlschema-1 ; 

XML Schema Part 2: Datatypes : http://www.w3.org/TR/xmlschema-2. 

Pour la decouverte d'un service, les specifications referencees sont les suivantes : 

UDDI Version 2.04 API, Published Specification, Dated 19 July 2002 : http://uddi.org/pubs/Program- 
mersAPI-V2.04-Published-20020719.pdf; 

UDDI Version 2.03 Data Structure Reference, Published Specification, Dated 19 July 2002 : http:// 
uddi.org/pubs/DataStructure- V2. 03-Published-20020719.pdf ; 

Version 2.0 UDDI XML Schema 2001 : http://uddi.org/schema/uddi_v2.xsd ; 

UDDI Version 2.03 Replication Specification, Published Specification, Dated 19 July 2002 : http:// 
uddi.org/pubs/Replication-V2.03-Published-20020719.pdf; 
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• Version 2.03 Replication XML Schema 2001 : http://uddi.org/schema/uddi_v2replication.xsd ; 

• UDDI Version 2.03 XML Custody Schema : http://uddi.org/schema/uddi_v2custody.xsd ; 

• UDDI Version 2.01 Operator's Specification, Published Specification, Dated 19 July 2002 : http:// 
uddi. org/pubs/Operators- V2. 1 -Published-2002071 9.pdf. 

Enfin, les specifications referencees pour definir les regies de securite sont : 

• RFC2818: HTTP Over TLS : http://www.ietf.org/rfc/rfc2818.txt ; 

• RFC2246: The TLS Protocol Version 1.0 : http://www.ietf.org/rfc/rfc2246.txt ; 

• The SSL Protocol Version 3.0 : http://wp.netscape.com/eng/ssl3/draft302.txt ; 

• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile : http://www.ietf.org/ 
rfcZrfc2459.txt. 

Les impacts des regies enoncees dans cette premiere version du profil de base sont precises dans les 
chapitres de la deuxieme partie du livre qui traitent des technologies Services Web et des specifica- 
tions associees. 



Mise a I'ecart de I'encodage SOAP (section 5) ? 

La premiere version du profil de base semble vouloir ecarter le format « rpc/encoded ». Les auteurs utilisent une 
phrase ambigue (sous la regie R1007) pour I'exprimer : « For interoperability, literal XML is preferred. » Curieuse- 
ment, cette phrase n'utilise pas le vocabulaire tres precis de la RFC21 1 9. Comme le souligne Roger Jennings dans 
un article publie par la revue XML & Web Services Magazine (voir ci-dessous), le terme « preferred » utilise releve 
de « I'euphemisme » et une expression telle que « For interoperability, messages MUST NOT use the SOAP rpcl 
encoded message format » aurait constitue « une representation plus precise de la position du BPWG (Web Services 
Basic Profile Working Group) ». 

Certains documents ou articles donnent des precisions sur ce probleme : 

• The Argument Against SOAP Encoding de Tim Ewald (Microsoft) : http://msdn.microsoft.com/ 
webservices/understanding/webservicebasics/default.aspx?pull=/library/en-us/dnsoap/html/argsoape.asp; 

• WS-I Draft Disallows rpc/encoded Format de Roger Jennings (OakLeaf Systems) : http:// 
www. fawcette. com/xmlmag/2002_ 1 0/online/webservices_rjennlngs_ 1 0_2 1_ 02/de fault, asp. 

Cette maniere alambiquee d'exprimer la mise a I'ecart d'un format d'echange necessite des eclaircissements. Elle 
va a I'encontre des efforts, menes depuis de nombreux mois par les animateurs du forum SOAP Builders, pour 
mettre au point des tests destines a verifier I'interoperabilite des diverses implementations SOAP et notamment 
des tests bases sur le format « rpc/encoded ». Les principals implementations du marche maitrisent bien ce 
format : I'etude de cas presentee a la fin de cet ouvrage s'appuie essentiellement sur ce format et met en oeuvre 
plusieurs implementations SOAP avec succes. 

Comme le note egalement Roger Jennings dans son article, le site XMethods referengait a mi-octobre 249 instan- 
ces de services Web, dont 128 accessibles au format « rpc/encoded ». La conclusion qu'en tire Roger Jennings 
est que « si le ratio rpc/encoded sur document/1 iteral constate sur le site XMethods est represented de la 
pratique generate de developpement des services Web, adopter le profil de base 1 .0 du WS-I en tant que 'standard' 
d'interoperabilite aurait pour effet de stigmatiser plus de la moitie des instances actuelles de services Web, en les 
considerant comme non conformes et par inference non interoperables. ». 
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Vers une interoperabilite generalisee 

Comme nous venons de le voir, les principaux acteurs dans le domaine des technologies liees aux 
services Web se sont tres vite preoccupes de s'assurer de l'interoperabilite de leurs produits et de 
revolution des specifications dans un sens favorable a cette interoperabilite. 

Cette preoccupation s'est tout d'abord manifested du point de vue des implementations avec la consti- 
tution de la communaute SOAP Builders et plus recemment UDDI Builders. 

Mais conscients de la necessite de prendre en compte cette problematique plus en amont de Pimple - 
mentation, c'est-a-dire au niveau des specifications, les plus grands acteurs ont decide de creer 
l'organisation WS-I dont le role essentiel est precisement de promouvoir et garantir cette interopera- 
bilite, en bonne intelligence avec les gardiens du processus de specification que sont, pour ne citer 
que les principaux, le W3C, 1'IETF ou le consortium OASIS. 

Cette prise de conscience etait necessaire. L' explosion des specifications disponibles et des proble- 
matiques adressees par ces specifications est impressionnante. La carte (roadmap) dressee par la 
communaute SOAP Builders donne une idee du chemin parcouru et du travail qu'il reste a fournir 
selon le point de vue des intervenants de cette communaute (voir http://www.xmlbus.com/learn/road- 
map.htm). 

Gageons que tous ces efforts conjoints permettront d'atteindre enfin cette interoperabilite que nous 
commencons a reellement entrevoir et a toucher du doigt, comme jamais auparavant. 

Ressources 

Differents sites de ressources se sont mis en place progressivement, afin de permettre aux utilisateurs 
de ces nouvelles technologies de verifier Favancement et la progression des plates-formes en matiere 
d'interoperabilite. Les liens indiques ci-dessous constituent une partie de ces ressources. 

Sites Internet (points d'acces, tests et resultats) 

HP-SOAP Interoperability Test : http://soap.bluestone.com/index.html 

IONA Web Services Interoperability Forum : http://www.xmlbus.com/interop 

IONA Interop Utilities : http://interop.xmlbus.com:7002 

Jake's SOAP Journal : http://jake.soapware.org 

Microsoft MSDN XML Web Services Interoperability Resources : http://msdn.microsoft.com/library/ 
default.asp?url=/library/en-us/dnsvcinter/html/globalxmlwebsrvinterop.asp 

Microsoft Soap Interop Server : http://www.mssoapinterop.org 

Microsoft Contribution to SOAP Version 1.2 Test Collection : http://www.mssoapinterop.org/soap12/ 
soap12-ms-tests.html 

PocketSOAP Interop test results : http://www.pocketsoap.com/weblog/soaplnterop 

SOAPBuilders.org : http://www.soapbuilders.org 



Le defi de I'interoperabilite 

Chapitre 17 

SOAP Builders Round I - Interoperability Lab « Round 1 » : http://www.xmethods.net/ilab 

SOAP Builders Round II - Interoperability Lab « Round 2 » : http://www.whitemesa.com/interop.htm 

SOAPBuilders Interoperability Lab « Round 2 » - Resultats implementation Apache SOAP 2.2+ 
et Axis : http://www.apache.org/~rubys/ApacheClientlnterop.html 

SOAPBuilders Interoperability Lab « Round 2 » - Resultats implementation Sun Microsystems : 
http://java.sun.com/wsinterop/sb/r2 

SOAPBuilders Interoperability Lab « Round 2 » - Resultats implementation Systinet WASP for 
Java et C++ : http://soap.systinet.net/interop/soap/index.html 

SOAPBuilders Interoperability Lab « Round 2 & 3 » - Resultats implementation PocketSOAP : 
http://www.pocketsoap.com/weblog/soaplnterop 

SOAP Builders Round III - Web Services Interoperability Testing : http://www.whitemesa.com/r3/ 
plan.html 

SOAPBuilders Interoperability Lab « Round 3 » : http://www.whitemesa.com/r3/interop3.html 

SOAPBuilders Interoperability Lab « Round 3 » - Resultats implementation Spray/Dolphin- 
Harbor : http://www.dolphinharbor.org/spray/r3/index.html 

SOAPBuilders Interoperability Lab « Round 3 » - Resultats implementation IONA XMLBus : 

http://interop.xmlbus.com:7002/interop3.html 

SOAPBuilders Interoperability Lab « Round 3 » - Resultats implementation IONA SQLData 

Systems : http://www.soapclient.com/interop/interopresultd.html 

SOAPBuilders Interoperability Lab « Round 3 » - Resultats implementation Sun Microsystems : 
http://java.sun.com/wsinterop/sb/r3 

SOAPBuilders Interoperability Lab « Round 3 » - Resultats implementation Systinet WASP for 
Java et C++ : http://soap.systinet.net/interop/wsdl/index.html 

SOAPBuilders Interoperability Lab « Round 4 » : http://www.whitemesa.net/r4/interop4.htmi 

SOAP Builders Round 5 @ Sun Microsystems : http://java.sun.com/wsinterop/sb/r5 

SOAPBuilders Interop Roadmap : http://www.xmlbus.com/learn/roadmap.htm 

SOAP Builders @ Sun Microsystems : http://java.sun.com/wsinterop/sb 

SQLData SOAP Interop Interface : http://www.soapclient.com/interop/interop.html 

Systinet UDDI Interop : http://soap.systinet.net/interop/uddi/index.html 

Userland Software Interopathon : http://www.soapware.org/interopathonPlan 

Mailing-lists 

• SOAP Builders : http://groups.yahoo.com/group/soapbuilders ou soapbuilders@yahoogroups.com 

• UDDI Builders : http://groups.yahoo.com/group/uddibuilders ou uddibuilders@yahoogroups.com 

• WSDL Issues : http://groups.yahoo.com/group/wsdlou wsdl@yahoogroups.com 

• Interopathon : http://groups.yahoo.com/group/interopathon ou interopathon@yahoogroups.com 
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Documents 



Advancing SOAP interoperability - A look at community SOAP interoperability efforts, Tony 
Hong, juin 2001 : http://www-106.ibm.com/developerworks/webservices/library/ws-asio/?dwzone=webservices 

Designing Your Web Service for Maximum Interoperability, Scott Seely, decembre 2001 : http:// 
msdn. microsoft, com/library/default, asp ?url=/library/en-us/dn_ voices_ webservice/html/service 1205200 1 . asp 

Developing Microsoft .NET Web Service Clients for EJB Web Services with IBM WebSphere Studio 
Application Developer and the Microsoft .NET Framework SDK, IBM : http:// 
www7b.software.ibm.com/wsdd/techjoumal/0204_wosnick/wosnick.html 

Developing WebSphere Business Component Composer-based Web Services and Microsoft .NET 
Clients, IBM : http://www7b.software.ibm.com/wsdd/library/tutorials/0208_alhamwy/0208_alhamwy_reg.html 

First look at the WS-I Basic Profile 1.0, IBM : http://www-106.ibm.com/developerworks/library/ws-basic- 
prof.htmi 

How IBM WebSphere Studio Application Developer Compares with Microsoft Visual Studio .NET 
- Part 3: Interoperability, IBM : http://www7b.software.ibm.com/wsdd/techjournal/0207_kraft/kraft.html 

HOW TO: Integrate a .NET Client with an Apache SOAP 2.2 XML Web Service, Microsoft : http:// 
support.microsoft.com/directory/article.asp?id=q307324&sd=msdn 

HOW TO: Integrate a SOAP Toolkit Client with an Apache SOAP 2.2 XML Web Service, Micro- 
soft : http://support. microsoft, com/directory/article, asp ?id=q3073 1 8&sd=msdn 

HOW TO: Integrate an Apache SOAP 2.2 Client with a SOAP Toolkit XML Web Service, Micro- 
soft : http:, ' 'support microsoft. com/directory/article. asp ?id=q307279&sd=msdn 

HOW TO: Integrate a PERL/SOAP Lite Client by Using a SOAP Toolkit or .NET XML Web Service, 
Microsoft : http://support.microsoft.com/directory/article.asp ?id=q308438&sd=msdn 

HOW TO: Integrate an Apache SOAP 2.2 Client with a .NET XML Web Service, Microsoft : http:// 
support.microsoft.com/directory/article.asp?id=q308466&sd=msdn 

Interoperability Testing, Apache : http://xmi.apache.org/soap/docs/guide/interop.html 

Interoperability with Other SOAP Implementations, Scott Seely, aout 2001 : http://msdn.micro- 
soft.com/library/default.asp?url=/library/en-us/dn_voices_webservice/html/service081 52001. asp 

Microsoft Contribution to SOAP Version 1.2 Test Collection, Microsoft : http://mssoapinterop.org/ 
soap 12/soap 12-ms-tests. html 

SOAP Interoperability Issues, Tony Hong : http://www.xmethods.net/soapbuilders/interop.html 

SOAP Interoperability with Microsoft and Apache Toolkits - A step by step guide : http://www.perfec- 
txml. com/articles/xml/soapguide. asp 

Publishing, Discovering, and Testing a Microsoft .NET-based Web Service using WebSphere Studio 
Application Developer : http://www7b.software.ibm.com/wsdd/techjournal/0202_lu/lu.html 

The Web services insider, Part 3: Apache and Microsoft — playing nice together : http://www- 
1 06. ibm. com/developerworks/iibrary/ws-ref3/?n-ws-524 1 

To infinity and beyond - the quest for SOAP interoperability, Sam Ruby, fevrier 2002 : http:// 
radio, weblogs. com/0 1 1 679/stories/2002/02/0 1/tolnfinityAndBeyondTheOuestForSoaplnteroperability. html 
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Web Services Framework for W3C Workshop on Web Services 11-12 April 2001, San Jose, CA 
USA, Microsoft/IBM : http://www.w3.org/2001/03/WSWS-popa/paper51 

Web Services: Interoperability Across Platforms, Applications, and Programming Languages - 
Microsoft, fevrier 2002 : http://www.microsoft.com/net/business/ws-i.asp 

Web Services Interoperability and SOAP, Keith Ballinger, mai 2001 : http://msdn.microsoft.com/library/ 
default, asp ?url=/library/en-us/dnsoap/html/soapinteropbkgnd. asp 

Web Services Interoperability between the WebSphere and .Net platforms, IBM developerWorks, 
aout 2002 : http://www-106.ibm.com/developerworks/webservices/library/i-wasnet 

The Web Services-Interoperability Organization Bylaws : http://xmi.coverpages.org/WS-i- 
Bylaws20020218.pdf 

WSDL Issues List : http://wsdl.soapware.org 
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Fiabilite des echanges 



La gestion de l'echange fiable est un sujet d'une importance cruciale pour le developpement et la 
diffusion de la technologie des services Web : il est impensable de pouvoir effectuer sur Internet, a 
grande echelle, dans le cadre de processus metier complexes, de veritables transactions administrati- 
ves et commerciales entre agents logiciels repartis sans que les echanges entre ces agents soient geres 
de facon fiable. Dans ce chapitre, nous allons presenter la problematique de la gestion de la fiabilite 
de l'echange, analyser ses enjeux et presenter deux solutions proposees actuellement. 

Ce chapitre est le premier de la partie « Infrastructure des services Web ». Nous pensons que la fiabi- 
lite des echanges est la premiere, et peut-etre la plus « fondamentale », des caracteristiques opera- 
tionnelles d'une infrastructure qui peut permettre la mise en ceuvre de processus metier complexes et 
critiques entre applications reparties sur Internet. II ne s'agit evidemment pas d'etablir des comparai- 
sons et des echelles d' importance avec les autres « services d' infrastructure » comme la gestion de la 
securite, la gestion des transactions et la gestion des processus metier. Mais il nous semble evident 
que la fiabilite des echanges est un service d' infrastructure essentiel, dont la disponibilite, par 
ailleurs, simplifie la mise en ceuvre des autres services de « niveau » superieur. 

Une constatation s'impose : le sujet n'a pas encore recu Fattention qu'il merite de la part des acteurs 
engages dans la technologie des services Web. II est interessant d'essayer d' analyser les causes de cet 
etrange « oubli », d'autant plus surprenant que le sujet, bien que complexe, ne presente pas veritable- 
ment de difficulte technique. II faut rappeler que des solutions proprietaires de gestion de l'echange 
fiable dans les reseaux prives, locaux et etendus, sont operationnelles depuis longtemps et ont meme 
atteint un niveau eleve de maturite en teraies de performance et de robustesse. 

La fiabilite des echanges entre applications reparties est la cible aujourd'hui de nombreuses techno- 
logies « proprietaires », qui peuvent par ailleurs interagir avec les technologies de services Web et 
etre utilisees par ces dernieres. Nous pouvons citer : 

• MQSeries, une technologie « historique » mise en ceuvre dans le monde IBM, notamment des 
grands systemes ; la aussi, il faut noter qu'IBM inclut MQSeries comme mecanisme de transport 
fiabilise pour SOAP (dans WebSphere 5.0, voir http://www-3.ibm.com/software/ts/mqseries/) ; 
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• MSMQ, une technologie Microsoft, qui offre des services comparables a MQSeries, dans le 
monde des applications COM/DCOM (voir http://www.microsoft.com/msmq/) ; 

• JMS (Java Message Service, voir http://java.sun.com/products/jms/), qui est une mise en ceuvre d'une 
messagerie asynchrone fiable entre applications Java reparties, au-dessus du protocole de 
communication RMI. Une implementation de JMS en tant que mecanisme de messagerie asyn- 
chrone et fiable entre applications et services Web a ete introduite dans le moteur SOAP 
Axis 1 .0, developpe par la communaute Apache (voir http://ws.apache.org/axis/). Grace a ce moteur, 
deux applications Java peuvent utiliser le modele et 1' API JMS pour s'echanger des messages en 
SOAP 1.1. 

Ces technologies, qui traditionnellement relevent de ce que Ton appelle les MOM (Message Oriented 
Middleware), sont utilisees couramment par les applications reparties intra-entreprise d'aujourd'hui. 
Elles introduisent un facteur de couplage fort, du point de vue technique et industriel, entre les appli- 
cations qui les utilisent. D'autres technologies proprietaires sont utilisees egalement dans le monde 
proche de l'EDI. 

Nous avons peut etre la un debut d'explication de l'etrange oubli dont la fiabilite des echanges est 
victime. La presence d'une offre importante d'outils proprietaires, conjuguee avec le fait que le 
champ d' application initial des technologies de services Web se trouve essentiellement a l'interieur 
du systeme d'information etendu de Fentreprise (la ou les besoins d'ouverture et d'interoperabilite ne 
sont pas absolus comme sur Internet), a peut-etre freine la prise de conscience de la necessite de 
mettre en ceuvre des protocoles d'echanges fiabilises sur Internet. A ces explications s'ajoute un 
facteur historique et culturel : la communaute des developpeurs de la technologie des services Web 
est issue de la mouvance « technologie des objets repartis », historiquement « rivale » de la 
mouvance MOM, et c'est cette derniere qui a accorde le plus d'attention au sujet de la fiabilite des 
echanges, et notamment a la gestion fiable de la messagerie asynchrone. 

Ce chapitre presente avec quelques details deux technologies d' infrastructure d'echanges fiables qui 
trouvent leur place dans le cadre de la technologie des services Web : 

• La technologie HTTPR est un protocole de transport fiable mis en ceuvre sur la base de HTTP 1.1. 
HTTPR ne fait pas partie, a proprement parler, de la famille des technologies de services Web, 
mais se situe plutot au niveau des « bases » ou « fondations » des services Web. HTTPR est 
propose par IBM et une implementation est disponible pour demonstration (incluse dans un 
support pack). 

• La technologie WS-Reliability est une extension de SOAP 1 . 1 qui permet de prendre en compte la 
fiabilite de l'echange de messages. Elle est proposee par Fujitsu Limited, Oracle Corp., Sonic 
Software Corp., Hitachi Ltd., NEC Corp. et Sun Microsystems. II s'agit la d'une specification 
extremement recente (9 Janvier 2003). A la date de la redaction de cet ouvrage, aucune implemen- 
tation de WS-Reliability n'est disponible. 

Chacune de ces deux technologies est concue pour l'interoperabilite et la compatibilite avec la 
technologie actuelle des services Web. La difference fondamentale est que le protocole HTTPR se 
situe au niveau transport et que son utilisation pour transporter des messages SOAP est transparente, 
tandis que WS-Reliability se situe au niveau messagerie : il s'agit d'une extension de SOAP, obtenue 
de facon standard par l'utilisation d'entrees de l'en-tete du message SOAP. 
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Le vrai probleme est que ces technologies, qui aujourd'hui presentent les niveaux d'ouverture et 
d'interoperabilite necessaires a la mise en ceuvre de services Web et qui sont sans doute interessantes 
et bien concues, ne depassent pas Fetat de la demonstration (HTTPR) ou sont encore au niveau de 
specifications « theoriques » (WS-Reliability). Mais surtout, ces technologies, que Ton peut 
considerer du niveau de 1' infrastructure de base, au meme titre que SOAP et WSDL, n'ont pas 
encore atteint les degres de generalite et d' acceptation necessaires pour leur mise en ceuvre. 

Pour leur part, IBM et Microsoft, dont Factivisme et la cooperation ont permis la naissance et le 
developpement de la technologie des services Web, ne sont pas encore vraiment rentres dans le vif du 
sujet, sans doute retardes par des offres etoffees d'outils proprietaries performants (la technologie 
HTTPR dTBM, que nous presentons dans ce chapitre, est presentee par ses auteurs memes comme 
une solution « minoritaire »). 

Nous considerons que F absence d'une solution standard pour la gestion de la fiabilite des echanges, 
correctement situee dans 1' architecture des technologies, constitue un frein important au develop- 
pement et a la diffusion des services Web, au moins aussi important que le pretendu retard du deve- 
loppement d'autres services d' infrastructure consideres comme plus critiques tels que la securite, les 
transactions, les processus metier. 

Ainsi se presente la situation a ce jour. Mais avant de presenter les solutions disponibles (a leur 
niveau de developpement) et comparer leurs avantages et inconvenients, il est utile de mieux cerner 
le probleme. 

Les enjeux 

Nous allons illustrer le probleme au moyen d'un exemple simple. Nous imaginons que (le systeme de 
reservation de) l'agence de voyages My Travel Inc. doit effectuer une reservation aupres (du systeme 
de reservation) de la compagnie aerienne Your Aiways Ltd, et que cette fonction est mise en ceuvre au 
moyen d'une requete/reponse SOAP 1.1, via une liaison SOAP/HTTP 

La situation est illustree figure 18-1. L application cliente et F application serveur mettent en ceuvre 
les codes applicatifs et, respectivement, le client et le serveur SOAP. Le client et le serveur HTTP 
jouent le role de composants dedies a la communication. 

La requete/reponse de reservation de place d' avion, vue par F application cliente, apparait comme un 
appel bloquant de procedure synchrone : 

1. La ligne d'execution de Fapplication cliente lance la requete et se met en attente de la reponse. 

2. L application serveur effectue le traitement complet de reservation, a la fin duquel la place est 
deflnitivement reservee, ou non reservee pour une raison « metier ». 

Pour rendre F exemple plus realiste, nous considerons que le traitement de la reservation de la part du 
serveur est transactionnel (transaction implicite). Cela veut dire que, si une defaillance ou une erreur 
devait surgit pendant le traitement, celui-ci est annule (rollback) et un compte rendu d'annulation est 
retourne au client. A F inverse, si le traitement reussit et est confirme (commit), le compte rendu de 
confirmation qui est retourne au client fait etat de F acceptation ou du refus de la reservation. 

Nous distinguons done, avec le traitement transactionnel, F acceptation ou le refus de reservation (qui 
est une decision de niveau applicatif, prise par la transaction reussie et confirmee), de la confirmation 
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ou annulation technique de la transaction (qui est du niveau de la gestion transactionnelle). Bien 
entendu, une place ne peut jamais etre reservee par une transaction annulee ! 

Une reservation acceptee, qui est forcement effectuee par une transaction confirmee, est un etat 
permanent et durable, qui ne pourrait eventuellement etre change que par une transaction compensa- 
toire d'« annulation » applicative (a ne pas confondre avec l'annulation technique de la transaction). 
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Figure 18-1 

Requete/reponse bloquante et synchrone. 



A partir de cet exemple, nous allons lister un certain nombre de cas de figure qui revelent les proble- 
mes lies a la fiabilite de l'echange, ou plutot a son manque de fiabilite. Ces cas se produisent lors des 
dysfonctionnements de la transmission de la requete et/ou de la reponse, ou bien lors des defaillances 
du client et/ou du serveur. Les situations qui en resultent peuvent etre generalement qualifiers de 
situations d' incertitude des agents sur Tissue des operations, ou bien de situations d'oubli, apres 
pannes franches, des traitements effectues ou ordonnances. 

Voici un echantillon des cas d' incertitude et d'oubli provoques par ces defaillances : 

• La requete a ete transmise au serveur, mais le serveur peut avoir detecte un probleme de connexion 
et decide de ne pas effectuer le traitement. Le client, apres depassement du delai d'attente maximal 
(timeout), se trouve dans 1' incertitude quant au sort de sa requete. 

• Le serveur a re5u la requete, a commence le traitement et est tombe en panne tranche. Au redemar- 
rage, la transaction est reprise, completee et confirmee. Le serveur ne peut pas communiquer la 
confirmation de la transaction au client et ne pourra jamais le faire apres redemarrage (car le client 
est sorti de Fattente du retour de l'invocation). 

• Le serveur a re§u la requete et execute le traitement qui s'est termine avec succes et a ete confirme. 
La reponse du serveur, avec le compte rendu de succes, est emise, mais ne parvient jamais au client 
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a cause d'une defaillance de la connexion. Le serveur n'est pas en mesure de savoir si le client a 
recu le compte rendu ou n'est pas en mesure de compenser la transaction. Le client, apres depas- 
sement du delai d'attente maximal (timeout), ne sait pas que la reservation de place a ete effectuee. 

• Le serveur a recu la requete et a execute le traitement qui s'est termine avec succes et a ete confrrme. 
La reponse du serveur, avec le compte rendu de succes, est emise, mais elle ne parvient jamais au 
client a cause du depassement du delai d'attente maximal (temps de latence trop important). 

• Le client tombe en panne franche entre remission de la requete et la reception de la reponse. Apres 
redemarrage, il a perdu toute information sur remission de la requete et il ne sait pas traiter l'even- 
tuelle reponse (quel que soit le contenu de cette reponse) qu'il est susceptible de recevoir apres 
redemarrage. 

• Le serveur tombe en panne franche apres reception de la requete mais avant le demarrage du trai- 
tement. II ne traite done pas la requete. Apres redemarrage, le serveur a oublie le fait d' avoir recu 
la requete et done n'effectue aucune action consequente. Le client, apres depassement du delai 
d'attente maximal, est dans une situation d' incertitude quant au traitement de sa requete. 

• Le serveur recoit la requete, effectue le traitement qui se termine avec succes (avec, par exemple, 
une reservation de place) et tombe en panne franche avant emission de la reponse. Apres redemar- 
rage, il a perdu toute information sur la transaction effectuee et sur la reponse a transmettre. Le 
client, apres depassement de delai d'attente maximal, est dans une situation d'incertitude par 
rapport au traitement de sa requete. 

• Scenario « catastrophe » : le client emet la requete et tombe en panne franche ; le serveur recoit la 
requete, effectue le traitement qui se termine avec succes (avec, par exemple, une reservation de 
place a la clef) et tombe en panne franche avant emission de la reponse. Apres redemarrage, le 
serveur a perdu toute information sur la transaction effectuee et sur la reponse a transmettre. Apres 
redemarrage, le client a perdu toute information sur la requete effectuee. La place reste reservee 
mais son existence est oubliee et elle ne sera revendiquee par personne. 

Cette liste n'est pas exhaustive et peut etre enrichie par d'autres variantes, qui different sur le moment 
(avant, pendant, apres le transfert) et le lieu (le client, la connexion, le serveur) ou les defaillances se 
produisent et sur la nature de ces defaillances. 

En cas d'incertitude, la simple repetition de remission de la requete ou de la reponse n'est pas une 
solution en soi. Si la requete de reservation est transmise plusieurs fois, et si le serveur n'est pas capa- 
ble de reconnaitre les doublons, alors il effectuera plusieurs reservations de places pour une seule 
demande. A 1' inverse, si le client recoit plusieurs reponses et n'est pas capable de reconnaitre les 
doublons, il pourra croire qu'il y a plusieurs reservations en conflit sur la meme place, alors qu'il n'a 
eu que plusieurs comptes rendus de la meme reservation. 

La semantique operationnelle des echanges 

La criticite de ces situations d'incertitude et d'oubli, et done des exigences de fiabilite de l'echange, 
depend egalement de la semantique et de la pragmatique du message. Nous pouvons distinguer trois 
niveaux de criticite : 

• Premier niveau : le message vehicule une simple interrogation (query), dont le traitement ne 
produit ni de transitions d'etat ni d'effets de bord. En cas de doute sur le succes de la transmission, 
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la logique applicative peut assurer la repetition de 1' interrogation lors d'une nouvelle connexion 
(que Ton suppose possible a etablir) jusqu'a Fobtention d'une reponse, qui peut etre la premiere 
d'une serie. Le seul inconvenient est le gaspillage de ressources de calcul et le verrouillage repete 
et long des donnees impliquees (dependant du degre d'isolation trans actionnelle de l'interroga- 
tion). L' interrogation est un cas typique d'operation idempotente, si elle n'est pas horodatee (lors 
de la recherche de donnees « a une certaine date »). 

• Deuxieme niveau : le message est declencheur d'une transition d'etat de 1' application receptrice et 
des ressources qu'elle gere. La situation est encore gerable par la logique applicative si 1' operation 
est idempotente, mais une grande partie des applications transactionnelles de mise a jour ne le sont 
pas. II faut done que l'application emettrice puisse se synchroniser avec l'application receptrice 
pour retablir la verite de la situation. La gestion applicative de ce type de synchronisation peut se 
reveler extraordinairement complexe. 

• Troisieme niveau : une variante du niveau de criticite precedent, encore plus difficile a traiter, 
prevoit le declenchement d' actions sur l'environnement {effets de bord) de la part du recepteur en 
consequence du traitement du message. 

Si, au niveau de la simple interrogation, la situation peut etre tenue sous controle relativement facile- 
ment, il est evident que la prise en compte de 1' incertitude de l'oubli de la part de la logique applicative 
pour des traitements de deuxieme ou troisieme niveau, cote emetteur comme cote recepteur, se traduit 
par une augmentation tres importante, voire insupportable, de la complexite des applications. Cette 
complexite excessive est due a l'imbrication inevitable d'une logique metier deja complexe en elle- 
meme (les regies de gestion qui regissent la reservation de places d' avion) avec la logique technique de 
prise en charge des defaillances reparties. 

La bonne solution reside sans aucun doute dans la separation des problemes et done dans la mise en 
ceuvre d'une infrastructure d'echange fiable, capable de faire face aux defaillances de l'emetteur, du 
recepteur et du canal de transmission. Cependant, pour proceder ainsi, il est necessaire de donner une 
definition precise de ce que Ton entend par echange fiable, et ensuite de decliner cette definition dans 
1' architecture generate des technologies de services Web. 

L'echange fiable 

La transmission de messages met en jeu un agent emetteur, un canal de transmission et un agent 
recepteur. Un mecanisme de transmission de messages totalement fiable est celui dans lequel : 

• Chaque message est remis au recepteur exactement unefois dans la sequence d 'emission, ou pas 
du tout. Dans le cas d'impossibilite averee de remise du message, le mecanisme produit un compte 
rendu fiable, a l'intention de l'emetteur, de l'echec definitif de la remise. 

• Les messages et les etats d' emission (messages a emettre, messages emis, messages remis) sont 
persistants (ils resistent a la panne franche de l'emetteur) et durables (ils resistent aux defaillances 
partielles des dispositifs de persistance de l'emetteur). 

• Les messages et les etats de reception (message re§u, message consomme) sont persistants (ils 
resistent a la panne franche du recepteur) et durables (ils resistent aux defaillances partielles des 
dispositifs de persistance du recepteur). 



Fiabilite des echanges 

Chapitre 18 

L'affaiblissement de tout ou partie de ces contraintes est ainsi caracterise : 

• Protocole partiellement fiable : le message est remis au mains une fois, mais peut etre remis 
plusieurs fois (doublons). Le protocole fiable suffit pour les messages idempotents. 

• Protocole partiellement fiable : le message est remis au plus une fois, en evitant done les 
doublons. Le protocole partiellement fiable est adapte aux messages non idempotents et non 
critiques. 

• Protocole non ordonne : un protocole peut en meme temps garantir la remise du message exacte- 
ment une fois, et ne pas garantir la livraison dans la sequence d' emission. 

L'emetteur, le canal et le recepteur sont tous concernes par la fiabilite de l'echange. II s'agit de 
garantir : 

• la fiabilite de la transmission, a savoir la prise en compte de la possibilite de defaillance temporaire 
du canal, defaillance qui n'est eventuellement pas detectee immediatement, ni par l'emetteur ni par 
le recepteur ; 

• la fiabilite des fonctions d' emission et de reception, a savoir la prise en compte de la possibilite de 
defaillance temporaire de Femetteur et du recepteur. 

Deux mecanismes de base assurent la mise en ceuvre de l'echange fiable : 

• Face aux defaillances temporaires du canal, la mise en ceuvre de la repetition de remission de 
messages, couplee avec un mecanisme qui permet de gerer les doublons et, eventuellement, l'ordre 
temporel des messages. Le message est emis par Femetteur autant de fois qu'il est necessaire pour 
obtenir la certitude de sa remise au recepteur. Des mecanismes de prevention, de reconnaissance et 
de traitement des doublons et des messages hors sequence sont mis en ceuvre. 

• Face aux defaillances temporaires de Femetteur et du recepteur, la prise en charge de la persis- 
tance des messages a Femission et a la reception, couplee avec la gestion transactionnelle des 
etats d' emission et de reception. Pour assurer, en plus de la persistance, la durabilite, a savoir 
un niveau de resistance aux defaillances des systemes de sauvegarde, ceux-ci peuvent etre 
redondants. 

En resume, les proprietes « fonctionnelles » d'un protocole d'echange fiable sont : 

• la garantie de livraison, qui assure qu'un message identifie est livre, dans son integrite, au 
moins une fois, ou bien qu'un compte rendu fiable d'impossibilite de livraison est retourne a 
F expedite ur ; 

• la suppression des doublons, qui assure qu'un message identifie ne sera jamais livre en double a 
son destinataire ; 

• le respect de la sequence, qui assure qu'un groupe de messages produits par l'expediteur dans une 
sequence temporelle (ordre total) sera livre dans la meme sequence temporelle au destinataire (le 
respect de la sequence peut s'appliquer si et seulement si la garantie de livraison et la suppression 
des doublons sont assures). 

La gestion des priorites s'apparente a la gestion dynamique de la sequence des messages. 
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Les degres de fiabilite, presentes dans le tableau suivant, sont obtenus par la combinaison de ces fonctions. 
Degres et fonctions de fiabilite de I'echange 



' " — — _________ Fonction Garantie Suppression Respect de la sequence 

Degre ' — — ________ de livraison des doublons 


Partiellement fiable 
(au plus une fois) 


NON 


OUI 


NON 


Partiellement fiable 
(au moins une fois) 


OUI 


NON 


NON 


Fiable 

(exactement une fois) 


OUI 


OUI 


NON 


Totalement fiable 

(exactement une fois et en sequence) 


OUI 


OUI 


OUI 


Totalement fiable avec priorites 

(exactement une fois 

et en sequence dynamique) 


OUI 


OUI 


OUI 
(gestion de la sequence dynamique) 



Pour eviter tout malentendu, il faut rappeler que la notion de fiabilite des echanges est completement 
relative : la terminologie employee, par exemple « echange totalement fiable » est conventionnelle. 
Lorsque nous citons des dysfonctionnements du reseau ou des pannes franches des agents, nous 
faisons reference a des defaillances temporaires et recuperables dans un laps de temps raisonnable. 
Les moyens et les astuces techniques presentes dans ce chapitre ne tiennent evidemment pas face a la 
destruction massive des equipements. Pour se proteger autant que Ton peut de ce type de risques, il 
faut mettre en ceuvre des moyens physiques de protection des systemes et des reseaux. 

Un probleme d'architecture de specifications 

Nous avons vu que la gestion de I'echange fiable n'est pas un probleme nouveau et que les technolo- 
gies capables de F assurer dans un contexte « ferme » sont disponibles depuis longtemps. II s'agit de 
technologies proprietaries, mises en ceuvre couramment entre applications reparties sur un reseau 
local, qui impliquent un niveau de couplage fort entre les applications participant a I'echange. 

Le probleme nouveau pose par la technologie des services Web est celui de V interoperabilite : 
I'echange fiable doit etre obtenu entre applications faiblement couplees et par le biais d'un protocole 
ouvert, standard et independant des technologies de mise en ceuvre, notamment des technologies qui 
assurent la persistance des messages et la gestion transactionnelle des etats d' emission et de reception. 

Par exemple, un agent emetteur fiable, dont les mecanismes de persistance des messages et de gestion 
transactionnelle des etats sont implementes en Java, doit pouvoir transmettre un message, par le biais 
d'un protocole d' echange fiable standard, a un agent recepteur fiable, dont les memes mecanismes 
sont implementes en .NET. 

Comme pour les autres technologies de services Web, ce resultat ne peut etre obtenu que si les 
conditions suivantes sont reunies : 

• Parution de specifications, largement acceptees, d'un protocole d'echange fiable, c'est-a-dire d'un 
format d'echange et des regies de comportement des agents logiciels impliques, et d'un fonnalisme 
pour decrire les engagements contractuels sur la fiabilite de I'echange des agents participants. 
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• Disponibilite concrete de plusieurs implementations de ces specifications, baties sur des techno- 
logies heterogenes et capables d'interoperer entre elles. 

La technologie presentant les caracteristiques listees ci-avant n'est pas disponible a ce jour. Ce 
chapitre ne fait done qu'une analyse theorique du probleme et des solutions envisageables. Nous 
avons evoque des raisons industrielles et commerciales qui peuvent expliquer ce retard. Ces 
raisons exceptees, il reste cependant un probleme technologique qui n'a pas de solution evidente. 
Ce n'est pas un probleme d'implementation : il s'agit plutot d'un probleme d' architecture de 
V ensemble des technologies de services Web. 

La premiere difficulte que rencontre la specification d'un protocole d'echange fiable interoperable 
reside dans ce que nous allons appeler le probleme du niveau d'accrochage du protocole. 

Les mecanismes qui assurent la gestion de l'echange fiable pour les services Web peuvent etre mis en 
ceuvre : 

• au niveau message : au niveau du protocole de messagerie, par exemple, sous forme d'une extension 
« fiable » du protocole SOAP ; 

• au niveau transport : au niveau des protocoles de transport, en mettant en ceuvre une liaison standard 
entre SOAP et un protocole de transport « fiable ». 

Dans le premier cas, ce sont l'emetteur et le recepteur SOAP qui prennent en charge la gestion de 
l'echange fiable en liaison avec plusieurs protocoles de transport, tandis que, dans le deuxieme cas, 
cette gestion est deleguee aux composants qui gerent le protocole de transport. Dans les deux 
circonstances, la formalisation des engagements contractuels des interlocuteurs de l'echange fiable 
doit etre mise en ceuvre par le biais d'une extension standard de WSDL. 

Dans ce chapitre, nous allons presenter deux technologies, HTTPR et WS -Reliability, qui sont 
paradigmatiques par rapport aux approches de la gestion de l'echange fiable (voir figure 18-2), 
respectivement au niveau transport et au niveau message. Nous allons ensuite exposer les avantages 
et inconvenients de chacune des approches. 
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Figure 18-2 

Deux approches de gestion de l'echange fiable. 
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HTTPR 

HTTPR (Reliable Hypertext Transfer Protocol) est un protocole de transport fiable de messages 
mis en ceuvre grace a l'utilisation de HTTP comme protocole de transport. II assure l'echange 
fiable des messages en presence de defaillances du canal de transmission et des agents logiciels qui 
participent a l'echange. 

Le protocole HTTPR est constitue de deux specifications complementaires : 

• la specification du format des entites HTTPR emboitees dans les requetes et les reponses 
HTTP : les entites ainsi formees ont pour vocation de transporter les messages applicatifs et les 
metadonnees HTTPR ; 

• la specification d'un ensemble de regies de comportement des agents HTTPR et de traitement 
des entites HTTPR. La mise en ceuvre de ces regies permet d' assurer tous les niveaux de fiabilite 
du message. 

La specification HTTPR est une specification de protocole et par consequent ne donne pas d'indi- 
cation sur le modele de conception et la technologie d' implementation des composants logiciels 
HTTPR. En revanche, la specification HTTPR etablit des exigences techniques sur 1' implementation, 
dont voici les plus importantes : 

• Les composants HTTPR doivent disposer d'une capacite de persistance de leurs etats et des 
messages applicatifs qu'ils gerent (pour la survie de ces informations a la panne franche de ces 
composants). Le protocole HTTPR specifie quelles informations doivent persister et a quel 
moment il faut les rendre persistantes. 

• Les agents HTTPR doivent disposer de la capacite de piloter le protocole HTTP sous-jacent, a 
savoir le client et le serveur HTTP, pour mettre en ceuvre correctement les operations de transfert 
et de synchronisation, meme en cas de defaillance de la transmission. 

Les relations entre HTTPR et HTTP 

HTTPR est mis en ceuvre directement sur le protocole HTTP. Tous les echanges HTTPR sont realises 
en utilisant le contenu des requetes HTTP POST et des reponses correlees. 

Le protocole HTTP peut etre etendu de facon standard par l'utilisation du HTTP Extension 
Framework (IETF - RFC2774). Les auteurs de HTTPR ont explicitement exclu cette voie car elle 
risque de limiter la diffusion du protocole, surtout au niveau des intermediaires (proxy-serveurs, 
passerelles). C'est la raison pour laquelle HTTPR n' est pas une extension de HTTP au sens du HTTP 
Extension Framework. 

En revanche, HTTPR emploie de facon standard le protocole HTTP : les entites HTTPR sont 
exclusivement vehiculees dans les corps des requetes/reponses HTTP. Dans ce sens, HTTPR peut 
etre vu comme un protocole de niveau applicatif qui utilise HTTP comme protocole de transport. 
Cela permet a une entite HTTPR d'etre emise, recue et acheminee par des agents HTTP (clients, 
serveurs et intermediaires) standards. HTTPR est egalement independant du protocole de messa- 
gerie applicative qui 1' emploie : un message applicatif est vu par HTTPR comme une chaine 
d'octets non interpretee. HTTPR se situe done comme un protocole intermediate entre HTTP et 
un protocole de messagerie comme SOAP. 
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References 

Trois versions des specifications HTTPR ont ete produites par I'equipe d'IBM (Andrew Banks, Jim Challenger, Paul 

Clarke, Doug Davis, Richard P King, Francis Parr, Karen Witting) : 

HTTPR Specification -Draft proposal -Version 1.0 13th July 2001 

HTTPR Specification - Draft proposal - Version 1.1 2001-12-03 

HTTPR Specification - 01 Avril2002 (http://www.ibm.com/developerworks/library/ws-httprspec/) 

Une introduction au protocole est presentee dans I'article : 

« A Primer for HTTPR » - An overview of the reliable HTTP protocol - July 2001 - Updated April 2002 

(voir http://www-106.ibm.com/developerworks/webservices/library/ws-phtt/) 

Du code pour demonstration et evaluation est librement disponible en I'etat avec le support pack (de la famille 

WebSphere MQ Family) Transport of SOAP and JMS with WebSphere MQ and HTTPR, publie le 1 4 avril 2002 (voir 

http://www-3.ibm.com/software/ts/mqseries/txppacs/ma0r.html) 

Le pack contient une demonstration du transport de messages SOAP par deux mecanismes de transport fiable : 

-WebSphere MQ (le nouveau nom pour MQSeries) ; 

- HTTPR. 

La demonstration peut etre configured pour tourner sur : 

- IBM Websphere Application Server (WAS) Enterprise Edition 4.0.2 ; 

- IBM Websphere Application Server Advanced 4.0 Single Server Edition ; 

- IBM Websphere "micro-edition" ; 
-Apache Tomcat 4.0.1 



HTTP 1.1 

HTTPR repose sur la version 1.1 de HTTP. De ce fait, il tire profit de toutes les fonctionnalites 
evoluees de cette version du protocole : 

• SSL : HTTPR peut utiliser HTTPS (on l'appellera HTTPSR) de facon transparente ; 

• connexion permanente (keep-alive par defaut) ; 

• transfert par tranches (chunked transfer encoding) ; 

• transfert en pipe-line (pipelining, a ne pas confondre avec 1' envoi groupe, ou boxcarrying, qui est 
le fonctionnement par defaut de HTTPR) ; 

• chaines d'acheminement avec proxy-serveurs, passerelles. 

Du fait de son independance du protocole de messagerie, HTTPR introduit le transfert groupe (par 
lots, boxcarring) de messages applicatifs comme fonctionnement standard. L' unite de transfert 
HTTPR n'est pas le message applicatif, mais une structure HTTPR (un lot) qui emboite un groupe de 
messages applicatifs. Le transfert d'un lot compose d'un seul message applicatif est une decision de 
1' agent HTTPR, non une limite du protocole. 

Le couplage du transfert groupe avec le codage par tranches donne un mecanisme extremement 
puissant, capable de transmettre de facon fiable des lots de messages applicatifs dont la faille est 
indeterminee a remission. Nous rappelons que le transfert par tranches HTTP est un mecanisme 
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par lequel le contenu du corps HTTP est transfere par tranches successives, de taille connue et 
limitee, mais en nombre indetermine, avec une convention pour marquer la derniere tranche (qui 
est vide et done de longueur nulle). Ce mecanisme permet le transfert de contenus HTTP de taille 
indeterminee en debut d' emission. 

On peut transferer par tranches non seulement le lot des messages (en appliquant le mecanisme stan- 
dard HTTP) mais aussi les messages eux-memes, pris distinctement : HTTPR reimplemente le meme 
systeme de codage par tranches et peut l'appliquer selectivement aux messages du lot (dont l'exis- 
tence, rappelons-le, est inconnue a HTTP). Le processus de transfert par tranches HTTPR ne rentre 
pas en conflit avec son homologue HTTP. 

Le couplage ulterieur avec le mecanisme de pipe-line HTTP 1.1, a savoir l'envoi successif de 
plusieurs requetes HTTP sans attente de reponse, avec la garantie fournie par HTTP de reception des 
reponses dans le meme ordre d'emission des requetes, autorise theoriquement les usages les plus 
divers dans les applications les plus critiques, avec les plus hauts debits et les exigences les plus 
elevees de montee en puissance. 

En resume, HTTPR met en ceuvre le transport fiable, en pipe-line, de lots de taille indeterminee a 
remission, composes de messages eux-memes de taille indeterminee, sur des chaines d'acheminement 
formees de serveurs HTTP (proxy serveurs, passerelles, pare-feu, etc.) « purs » et/ou d'agents HTTPR. 

Asymetrie d'HTTPR 

L'utilisation d'HTTP comme protocole de transport impose F asymetrie entre les participants a 
l'echange, e'est-a-dire entre le client et le serveur HTTPR, qui interagissent respectivement avec le 
client et le serveur HTTP. Cette asymetrie ne concerne que les roles HTTPR et en aucun cas les roles 
que les applications impliquees dans l'echange peuvent interpreter dans une relation de service. 

Par ailleurs, le client et le serveur HTTPR jouent chacun les roles d'emetteur et de recepteur de lots 
de messages. Les lots des messages peuvent etre « pousses » (commande PUSH) du client vers le 
serveur et aussi « tires » (commande PULL) du serveur vers le client. 

L asymetrie est inevitable en raison de l'utilisation d'HTTP et constitue le prix a payer pour 
beneficier des avantages techniques listes dans la section precedente (qui sont pratiquement tous 
du fait de HTTP 1.1) ainsi que de l'enorme diffusion d'HTTP. La consequence pratique de 
1' asymetrie est que V initiative de 1' interaction incombe toujours au client HTTPR. De ce fait, le 
pilotage de 1' execution du protocole est a la charge du client HTTPR, par remission de comman- 
des HTTPR appropriees, vehiculees par des requetes HTTP. Par exemple, il lui incombe de prendre 
1' initiative : 

• de confirmer au serveur HTTPR la reception reussie des lots de messages « tires » ; 

• de resynchroniser les etats du client et du serveur suite a des dysfonctionnements du reseau. 

Dans la suite du chapitre, on parlera d' 'interaction HTTPR pour designer le couple requete/reponse 
HTTP qui transporte les entites HTTPR. L'interaction HTTPR suit toujours le meme schema : le 
client HTTPR emet une requete HTTP POST standard qui vehicule une entite HTTPR contenant une 
commande HTTPR. Le serveur HTTPR emet alors la reponse correlee standard qui transporte egale- 
ment une entite HTTPR. La figure 18-3 illustre le cas le plus simple, sans codage du transfert par 
tranches. 
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Figure 18-3 
Interaction HTTPR. 

Plus precisement, la requete HTTPR (entite HTTPR dans la requete HTTP) inclut : 

• dans la partie « en-tete », la commande HTTPR accompagnee des informations complementaires 
et de status sous forme de parametres ; 

• dans la partie « corps », si la commande implique le transfert de messages applicatifs, un lot de ces 
messages, eventuellement code en tranches successives. 

La reponse HTTPR (entite HTTPR dans la reponse HTTP) inclut : 

• dans la partie en-tete, des informations de status et complementaires ; 

• dans la partie corps, si la commande contenue dans la requete implique le transfert de messages appli- 
catifs, un lot de ces messages (qui peut etre vide), eventuellement code en tranches successives. 



L 'identification des serveurs et des canaux 

Un agent HTTPR (client et serveur) est identifie, pour les besoins du protocole, par un URI ainsi 
constitue : 

| httpr :// host[: port]/ Servi ceHame 

L' application destinataire d'un message applicatif est identifiee par l'URI : 

| httpr :// host[: port]/ Servi ceNameftAppl i cati on 

Un lot de message est transmis a un seul agent HTTPR. Chaque message applicatif du lot s'adresse a 
une application identifiee par un URI dont la partie httpr :llhost\.: port]/ Servi ceNatne est l'URI de 
1' agent HTTPR. 
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Chaque interaction HTTPR est associee explicitement ou implicitement a un canal HTTPR. Un canal 
est identifie par la triple ordonnee : 

[URI du client HTTPR, identifiant du canal, URI du serveur HTTPR] 

A un canal est associee, a un moment donne, une et une seule connexion TCP/IP, et done, dans la 
duree, une succession sans recouvrement temporel de connexions TCP/IP. Bien evidemment, un 
client et un serveur HTTPR peuvent interagir en meme temps sur plusieurs canaux independants (et 
done sur plusieurs connexions) et chaque canal peut servir plusieurs couples d' applications (qui, a 
leur tour, peuvent utiliser plusieurs canaux). 

La notion a" application destinataire, identifiee par httpr.llhost[:port]/ServiceName#Application est tres 
souple. Ainsi, il est tout a fait pensable de creer dynamiquement des « applications » volatiles. Par 
exemple, un service de gestion de comptes bancaires peut creer a la volee une application volatile 
pour chaque compte interroge et manipule par ses clients (avec, par exemple, le suffixe #Appli cation 
en relation avec le numero de compte). Un compte interroge et manipule sera traite comme une appli- 
cation volatile dotee d'un URI temporaire pour le temps de l'echange. 

Les transactions et les agents HTTPR 

L' operation de remise d'un lot de messages applicatifs est appelee transaction HTTPR. Ce terme est 
specifique a HTTPR, meme si la transaction HTTPR implique des transactions internes (au sens de la 
gestion transactionnelle) chez l'emetteur et le recepteur. La transaction HTTPR est un processus en 
trois etapes qui implique l'emetteur, le recepteur et le canal : 

1 . preparation du lot de messages, avec sauvegarde d' informations d'etat de la part de l'emetteur 
HTTPR avant emission : cette sauvegarde est effectuee dans un cadre trans actionnel ; 

2. transfert du lot de messages, via une requete ou une reponse HTTP ; 

3. sauvegarde apres reception des messages du lot et des informations d'etat de la part du recepteur 
HTTPR : cette sauvegarde est effectuee dans un cadre trans actionnel. 

II est de la responsabilite de l'emetteur HTTPR d'attribuer a chaque transaction un identifiant 
unique dans le canal, transmis dans l'en-tete HTTPR de 1' operation de transfert. L'identifiant de 
transaction HTTPR est un entier positif, compris entre 1 et (2 64 - 1) et genere dans l'ordre croissant 
de la sequence des entiers. La portee spatiale de l'identifiant est le canal et sa portee temporelle un 
intervalle de temps ouvert et ferme par des interactions HTTPR de synchronisation. Sur un canal, 
il y a done deux sequences independantes (et numerotees independamment) de transactions 
HTTPR : la sequence client-a-serveur et la sequence serveur-a-client. 

L'association entre un message et un identifiant de transaction HTTPR est dynamique et geree par l'emet- 
teur. II est important de noter que ce qui est identifie par numerotation progressive est bien la tran- 
saction HTTPR et non 1' ensemble de messages du lot qui lui est temporairement associe. Siunlot 
de messages associe a une transaction HTTPR n'est pas correctement transfere au recepteur HTTPR, par 
exemple en raison d'un dysfonctionnement de la connexion, celui-ci informe l'emetteur HTTPR 
que la transaction HTTPR est annulee. L'emetteur liberera les messages de leur association avec la 
transaction HTTPR annulee et formera un nouveau lot de messages a envoyer, pas forcement iden- 
tique au premier, qu'il associera a une nouvelle transaction HTTPR dotee d'un nouvel identifiant. 
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Une transaction HTTPR peut reussir, echouer ou rester dans un etat incertain. Elle reussit si les trois 
etapes du processus presente ci-avant se deroulent avec succes. Elle est ensuite confirmee par le recepteur 
HTTPR, qui retourne Facquittement avec le statut de la transaction HTTPR (« confirmee ») a l'emetteur, 
et enfin rend disponibles les messages recus pour consommation par les applications destinataires. 

Une transaction HTTPR echoue si la deuxieme ou la troisieme etape du processus echoue (si la 
premiere etape echoue, la transaction HTTPR n'est pas creee). En cas d'echec, le transfert du lot ne 
s'est pas deroule correctement en raison de dysfonctionnements reseau, ou bien la transaction interne de 
sauvegarde des messages et de Fetat du recepteur a echoue. La transaction HTTPR est annulee par le 
recepteur, qui retourne Facquittement avec le statut de la transaction HTTPR (« annulee ») a l'emetteur. 
Les messages du lot doivent etre transmis a nouveau dans le cadre d'une nouvelle transaction HTTPR. 

Une transaction HTTPR est mise en doute par le recepteur lorsque celui-ci est dans F incertitude 
quant a F issue de la troisieme etape du processus : la transaction interne de sauvegarde n'est ni 
confirmee ni annulee. Dans cette situation, due en principe a un dysfonctionnement grave du systeme 
de persistance du recepteur, le protocole HTTPR impose F arret immediat des echanges de messages 
et la synchronisation entre les agents jusqu'a elimination de Fincertitude. 

La specification HTTPR ne pose pas d' exigences relatives a la conception et a la realisation des 
agents HTTPR. Elle n' impose notamment pas de contraintes : 

• sur F interface programmatique entre les applications et les agents HTTPR ; 

• sur le protocole de messagerie qui utilise HTTPR comme protocole d'echange fiable ; 

• sur F implementation des systemes de persistance des etats et des messages. 

Le protocole de messagerie SOAP peut etre mis en ceuvre sur HTTPR de facon totalement transpa- 
rente par une liaison standard SOAP/HTTPR. Le format et le contenu des messages SOAP ne sont 
pas affectes par le fait d'etre transferes dans une entite HTTPR. 

Le format de I 'entite HTTPR 

La requete et la reponse d'une interaction HTTPR sont transportees dans le corps de la requete HTTP 
POST et de la reponse HTTP correlee. La structure generate du message HTTP qui vehicule une 
entite HTTPR est illustree figure 18-4. 

L entite HTTPR (requete et reponse) est composee d'un en-tete, comprenant les parametres HTTPR, 
et eventuellement d'un lot de messages (pour les requetes PUSH et EXCHANGE ainsi que pour les repon- 
ses non vides PULL et EXCHANGE). L entite HTTPR peut etre codee pour le transfert par tranches, ce qui 
explique la presence a la fin du corps HTTP de la marque de terminaison (derniere tranche vide). 

Chaque message est une structure autonome, avec un en-tete et un corps qui contient le message, 
comme une chaine d' octets non interpretee. 

Le lot de messages se termine par un marqueur de fin, (payload-disposition) qui a en outre la fonc- 
tion d'indiquer si le lot est valide, a savoir si la transaction interne de preparation du transfert du lot 
et le debut du transfert lui-meme se sont correctement (ou incorrectement) deroules. 

Exemple 

Dans l'exemple presente figure 18-5, un message HTTP vehicule une requete PUSH HTTPR (non 
codee en tranches) avec un lot de messages compose d'un seul message SOAP. 
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Figure 18-4 

Format du message (requete et reponse) avec lot de messages. 
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Figure 18-5 

Message HTTP vehicidant un message SOAP via une entite HTTPR. 
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Les commandes HTTPR 

Les commandes HTTPR sont ail nombre de cinq, plus precisement : 

• deux commandes de synchronisation : GET-RESPONDER-INFO, REPORT ; 

• trois commandes de transfert de messages applicatifs : PUSH, PULL, EXCHANGE. 

Les commandes HTTPR sont exclusivement transportees dans les requetes HTTPR et done sont 
toujours emises par le client HTTPR. 

Chaque interaction HTTPR, en plus des informations necessaires a la transmission de la commande 
et de son resultat, peut vehiculer des informations propres aux commandes emises dans des interactions 
anterieures. 

GET-RESPONDER-INFO 

L'interaction GET-RESPONDER-INFO est utilisee par le client HTTPR pour negocier avec le serveur 
HTTPR le « niveau de service ». La requete HTTPR communique le niveau de service que le client 
est capable d'assurer et qu'il demande au serveur, au moyen d'un vecteur de « capacites ». La 
reponse du serveur renvoie des valeurs de capacites reduites (jamais de valeurs augmentees). II s'agit 
d'une « negociation » avec un echange, car la reponse du serveur ne peut etre renegociee par la suite 
(dans le cadre de la meme session). 

L'interaction GET-RESPONDER-INFO constitue l'ouverture d'une session HTTPR, qui est active apres la 
reponse du serveur et ouverte sur la base des valeurs corrigees par le serveur. La session peut etre 
arretee (a tout moment) par le client au moyen d'une commande REPORT ou par le serveur par le biais 
de l'inclusion de l'en-tete HTTPR sessi on : end dans la reponse de n'importe quelle interaction. 

Gestion des sessions 

HTTPR permet trois modes de fonctionnement de l'interaction entre le client et le serveur : 

• le mode sans session ; 

• le mode session simple ; 

• le mode session pipe-line. 

Mode sans session 

L'ouverture prealable d'une session n'est pas indispensable aux interactions HTTPR, qui peuvent 
etre effectuees directement sur le canal. Dans ce cas, les valeurs par defaut des capacites s'appliquent 
a chaque interaction, sauf si elles sont modinees dans l'interaction meme. La procedure de negocia- 
tion decrite pour GET-RESPONDER-INFO s'applique, mais la portee spatiale et temporelle du resultat est 
limitee a l'interaction dans laquelle la negociation a lieu. 

Le client HTTPR peut inclure un vecteur de capacites dans toute requete. Le serveur peut soit rejeter 
la commande par un retour d'erreur, soit l'executer avec des valeurs de capacites differentes et repon- 
dre avec ces nouvelles valeurs. Pour un certain nombre de capacites, cette negociation n'a pas de 
veritables consequences a cause de sa portee limitee a l'interaction en cours. 

Dans le mode sans session, les interactions sur un canal ont lieu sur une seule connexion TCP/IP ou 
bien sur une sequence temporelle de connexions TCP/IP successives sans recouvrement. Ces 
connexions ne peuvent pas etre utilisees en mode pipe-line HTTP. 
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Mode session simple 

Dans le mode session simple, le dialogue est toujours initialise par le client via une commande GET- 
RESPONDER-INFO qui transporte un vecteur de capacites. Apres reponse du serveur, susceptible de 
corriger certaines valeurs du vecteur, et jusqu'a l'arret de la session, la session est active. 

La session est associee a un canal. Un canal est done soit utilise par une et une seule session, soit 
utilise en mode sans session. Une session peut utiliser seulement un canal, qui a son tour fonctionne 
sur une connexion TCP/IP ou sur une sequence temporelle sans recouvrement de connexions TCP/IP. 
En mode session simple, comme en mode sans session, le pipe-line de messages n'est pas autorise. 

Mode session pipe-line 

II s'agit du mode de fonctionnement le plus sophistique. La longueur du train des messages (nombre maxi- 
mal de messages presents en meme temps dans le pipe-line) est negociee dans le vecteur de capacites. 

Parfois, apres une situation d'erreur, il est necessaire d'arreter une session et d'en ouvrir une 
nouvelle. Si, par exemple, il y a cinq requetes PUSH dans le pipe -line client-a-serveur et que, pendant 
la remise du troisieme lot, le serveur constate une defaillance de son systeme de persistance, il ferme 
de facon volontaire la session en posant le parametre sessi on : end dans la reponse. II ne prendra plus 
en compte les requetes successives qui se reclament de la session qu'il vient de fermer. Le client, a la 
reception de la troisieme reponse, demande l'ouverture d'une nouvelle session sur le meme canal 
avec GET-RESPONDER-INFO, et emet une commande REPORT afin de resynchroniser les etats de reception 
et d'emission du client et du serveur. 

Le vecteur des capacites 

Le vecteur des capacites est un ensemble de parametres qui determinent le niveau de qualite de 
l'echange HTTPR dans une session ou une interaction HTTPR (mode sans session). Ces parametres 
expriment des informations quantitatives (des tailles, des delais) et des informations qualitatives sur 
les fonctionnalites prises en charge par les serveurs. Les parametres sont dotes de valeurs par defaut. 
II n'y a pas de memoire des capacites d'une session (ou d'une interaction) lors de l'ouverture des 
sessions suivantes sur le meme ou sur un autre canal : ce sont les valeurs par defaut qui jouent en 
l'absence de declarations explicites. 

Tableau des capacites 



Capacite Description Defaut 


idle_session_interval 


Le delai maximal (en secondes) de permanence de la session 
dans I'etat inactif entre deux requetes. 


10s 


empty_batch_del ay 


Delai d'attente maximal (en millisecondes) de nouveaux messa- 
ges dans la file de sortie vide du serveur au moment de la recep- 
tion de la requete PULL, avant la construction de la reponse. 


1 000 ms 


max_latency 


Delai maximal (en millisecondes) de remplissage d'un lot de 
messages lors de la reponse PULL. Le laps de temps est calcule 
a partir de inclusion du premier message dans le lot. 


100 ms 


max wait next 

: : 


Delai maximal d'attente (en millisecondes) de nouveaux messa- 
ges a inclure dans une reponse PULL a partir de I'inclusion du 
dernier. 


100 ms 
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Tableau des capacites (suite) 



Capacite Description Defaut 


max_wait_batch 


Delai maximal (en millisecondes) a disposition du serveur pour 
construire la reponse PULL a partir de la reception de la requete. 


100 ms 


maximum_message_size 


La taille maximale du message applicatif. 


100 000 000 octets 


maximum_batch_size 


Le nombre maximal de messages applicatifs compris dans un lot. 


10 messages 


maximum_pipel ine_depth 


Le nombre maximal de messages d'un train (pipe-line). 


1 requete 


flows 


Les commandes de transfert de messages (PUSH, PULL, 
EXCHANGE ) prises en charge par le client et le serveur. 


PUSH + PULL + EXCHANGE 


session_support 


Les modes d'interaction : 

- SESSIONLESS (sans session), 

- SESSION (avec session). 

La session simple est specifiee par la valeur SESSION et la 
valeur 1 pour le parametre max1mum_p1peline_depth. La 
session pipe-line affecte une valeur superieure a 1 au parametre 
maximum_pipel ine_depth. 


SESSIONLESS 



PUSH 

La requete HTTPR PUSH permet a un client HTTPR de transferer un lot de messages a un serveur 
HTTPR sur un canal choisi. 

Le transfert est identifle par Fidentifiant de transaction HTTPR qui est unique dans la portee du canal 
(pour les interactions sans session) ou de la session dans laquelle l'interaction PUSH a lieu. 

La reponse vehicule un acquittement de la transaction HTTPR, avec les trois statuts possibles 
(« confirmee », « annulee », « mise en doute »). 

Dans un pipe-line de PUSH, les transactions HTTPR confirmees peuvent ne pas etre acquittees separe- 
ment. Le premier acquittement d'une transaction (quelle que soit Tissue) fait fonction d' acquittement 
avec statut « confirmee » des transactions precedentes qui n'avaient pas encore ete acquittees. Cela 
veut dire aussi que la premiere transaction d'un pipe-line annulee ou mise en doute doit etre imme- 
diatement acquittee avec son statut. 

La requete PUSH peut acheminer egalement l'acquittement et le resultat des transactions HTTPR des 
precedentes commandes PULL et EXCHANGE (transfert dans le sens serveur-a-client), si Tissue est la 
confirmation ou Tannulation. 

En cas de mise en doute de la transaction serveur-a-client precedente, le client doit synchroniser les 
etats via la commande REPORT. L'acquittement avec statut « mise en doute » est obligatoirement 
accompagne par la terminaison de la session et la decision d'arreter Techange de transactions sur le 
canal. Par la suite, le client demarre une nouvelle session et utilise la commande REPORT afin de se 
resynchroniser avec le serveur. 

PULL 

L'interaction HTTPR PULL permet a un client HTTPR de demander au serveur HTTPR la remise des 
messages par transfert d'un lot dans la reponse. 

La requete peut vehiculer l'acquittement et le resultat de la derniere transaction HTTPR serveur-a- 
client (requetes PULL ou EXCHANGE precedentes) si son statut est « confirmee » ou « annulee ». Comme 
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pour la commande PUSH, en cas de session pipe -line, les transactions de numero inferieur non encore 
acquittees sont acquittees automatiquement avec statut « confirmee » par le premier acquittement. 

Si le statut de la derniere transaction est « mise en doute », le client doit utiliser la commande REPORT, 
qui arrete le flux et resynchronise les agents. 

La reponse PULL vehicule un lot de messages avec un identifiant de transaction HTTPR genere par le 
serveur. Le lot peut, bien entendu, etre vide si le serveur n'a pas de messages serveur-a-client a trans- 
ferer. Dans ce cas, le serveur peut attendre la disponibilite de nouveaux messages applicatifs avant 
d'emettre la reponse HTTPR. Le jeu de delais maximaux, qui reglent cette attente, est etabli par le 
vecteur de capacites en vigueur. 

EXCHANGE 

La commande EXCHANGE combine les comportements de PUSH et PULL dans la meme interaction 
HTTPR. Elle permet par une seule et meme interaction : 

• de transferer un lot de messages dans le sens client-a-serveur avec un identifiant de transaction 
HTTPR dans la requete, ainsi que F acquittement des transactions precedentes dans le sens inverse ; 

• de transferer un lot de messages dans le sens serveur-a-client avec un identifiant de transaction 
HTTPR dans la reponse, ainsi que 1' acquittement des transactions precedentes dans le sens inverse. 

La requete et la reponse EXCHANGE transported respectivement les parametres des requetes et des 
reponses PUSH et PULL. 

Le protocole HTTPR ne gere pas de relation applicative entre les messages envoyes et les messages 
recus dans une interaction EXCHANGE. En revanche, il peut etre pilote par les composants qui gerent le 
protocole des messages pour transporter dans Finteraction EXCHANGE une requete/reponse applicative 
pseudo-synchrone : la transaction client-a-serveur vehicule une requete et la transaction serveur-a- 
client vehicule la reponse correlee. 

REPORT 

La commande HTTPR REPORT permet la synchronisation entre client et serveur. 

La requete permet au client de communiquer au serveur F identifiant de la derniere transaction HTTPR 
serveur-a-client acquittee, ainsi que F identifiant de la derniere transaction HTTPR client-a-serveur 
emise. 

La reponse communique au client Fidentifiant de la derniere transaction HTTPR client-a-serveur 
acquittee et celui de la derniere transaction HTTPR serveur-a-client emise. 

Du fait de la numerotation progressive des transactions sur le canal et dans la session (il s'agit en fait de 
deux numerotations independantes pour les directions de transfert client-a-serveur et serveur-a-client), 
Fidentifiant de la derniere transaction emise est forcement superieur ou egal a Fidentifiant de la derniere 
transaction acquittee par le recepteur (pour une meme direction de transfert et avant reinitialisation). 

Apres interaction REPORT : 

• L'emetteur (client, serveur) considere que les transactions dont Fidentifiant est inferieur ou egal a 
la derniere transaction acquittee sont a oublier. 
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• L'emetteur (client, serveur) considere que les transactions dont Fidentifiant est superieur a la derniere 
transaction confirmee et inferieur ou egal a la derniere transaction emise sont nulles et non avenues : 
les messages des lots impliques doivent etre mis a nouveau en attente de transfert. lis pourront etre 
reemis avec des transactions d'identifiants superieurs a celui de la derniere transaction emise. 

• Le recepteur (serveur, client) considere que les transactions dont l'identifiant est superieur a la 
derniere acquittee et inferieur ou egal a la derniere emise sont nulles et non avenues (et doivent etre 
rejetees si elles arrivent « en retard »). Les transactions acceptables qu'il recevra dans le futur 
devront imperativement posseder un identifiant superieur a la derniere transaction emise. 

La commande REPORT est utilisee chaque fois qu'il est necessaire de resynchroniser le client et le 
serveur et notamment : 

• suite a des situations d' incertitude dues aux defaillances de la connexion ou des systemes de 
persistance des serveurs ; 

• suite au redemarrage des serveurs apres une panne franche (le serveur peut provoquer un REPORT 
par differents moyen, par exemple en declarant le statut « mise en doute » d'une transaction recue). 

La commande REPORT peut egalement etre utilisee pour reinitialiser (a 0) la numerotation des transac- 
tions sur le canal (lorsque Ton sait qu'il n'y a pas de transactions « en retard »). 

Les transactions internes aux agents HTTPR 

Nous avons vu que les agents HTTPR, qu'ils soient clients ou serveurs HTTPR, peuvent jouer les 
roles d'emetteurs et recepteurs de lots de messages HTTPR. 

Les etats de l'emetteur HTTPR 

L'emetteur HTTPR est responsable de la sauvegarde permanente et durable, sur son systeme de persis- 
tance, de tous les messages produits par les applications expediences qui n'ont pas encore ete transferes 
aux applications destinataires ou qui sont lies a des transactions HTTPR non encore confirmees. Les 
messages qu'il gere sont dans trois etats possibles (le graphe d'etat est presente figure 18-6) : 

• produit : le message est produit par 1' application expeditrice et en attente de transfert ; 

• emis : le message a ete transfere dans le cadre d'une transaction qui n'est pas encore acquittee (ou 
a ete acquittee avec statut « mise en doute ») ; 

• remis : le message a ete transfere dans le cadre d'une transaction acquittee et confirmee (etat final). 

Le message revient a l'etat « produit », a partir de l'etat « emis », lorsque la transaction HTTPR a laquelle 
il est associe est annulee par le recepteur ou suite a une synchronisation (voir la commande REPORT). 




Figure 18-6 

Etats des messages geres par l'emetteur HTTPR. 
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Gestion des etats d'emission 

L'etat de l'emetteur HTTPR, par rapport a un canal ou a une session, est decrit par les variables suivantes : 

• l'identifiant de la derniere transaction HTTPR envoyee (initialise a 0) ; 

• les identifiants des transactions HTTPR envoyees et non encore acquittees ; 

• les messages associes aux transactions HTTPR envoyees et non encore acquittees ; 

• l'identifiant de la derniere transaction acquittee (initialise a 0) ; 

• le statut de la derniere transaction acquittee, avec comme valeurs possibles : « confirmee », 
« annulee », « mise en doute » (initialise a « confirmee »). 

L'emetteur attribue comme valeurs d'identifiant de transaction sur un canal des entiers positifs stric- 
tement croissants. II n'est pas necessaire que la sequence soit sans trous. 

Emission d'un lot de messages 

Pour derouler une transaction HTTPR, Femetteur, dans le cadre d'une transaction interne de preparation : 

• genere un identifiant de transaction HTTPR, superieur a la valeur de la derniere transaction envoyee ; 

• constitue un lot de messages a l'etat « produit », les passe a l'etat « emis » et associe ce lot a l'iden- 
tifiant de transaction. 

Apres sauvegarde de l'etat et confirmation de la transaction interne, l'emetteur transfere le lot de 
messages via une requete ou reponse HTTP. Si, pour une raison quelconque, la transaction interne est 
annulee, le lot de messages n'est pas transfere. 

En effet, le transfert du contenu de Fentite HTTPR via HTTP peut etre en concurrence avec le derou- 
lement de la transaction interne. En revanche, la transaction interne de preparation doit etre comple- 
tee et confirmee avant emission de la marque de fin (payl oad-di sposi t1 on) du lot HTTPR. Si la tran- 
saction interne est annulee, la marque de fin doit invalider le lot (payl oad-di sposi ti on : abort) et le 
recepteur doit annuler la transaction a la reception d'un lot invalide. 

Reception de I'acquittement venant du recepteur 

L'acquittement est accompagne du statut de la transaction chez le recepteur (« confirmee », « annulee », 
« mise en doute »). 

Confirmation 

En cas de confirmation, l'emetteur, dans le cadre d'une transaction interne de confirmation : 

1. memorise l'identifiant de la transaction comme identifiant de la derniere transaction acquittee ; 

2. passe les messages associes a la transaction a l'etat « remis » ; 

3. sauvegarde tous les changements d'etat en memoire secondare. 

Annulation 

En cas d' annulation, l'emetteur, dans le cadre d'une transaction interne d' annulation : 

1. memorise l'identifiant de la transaction comme identifiant de la derniere transaction acquittee ; 

2. remet les messages associes a la transaction a l'etat « produit » ; 

3. sauvegarde tous les changements d'etat en memoire secondaire. 
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Mise en doute 

En cas de mise en doute, la synchronisation avec le recepteur est necessaire, accompagnee eventuel- 
lement par le demarrage d'une nouvelle session (voirles commandes REPORT et GET- RESPONDER- INFO). 

Les etats du recepteur HTTPR 

Le recepteur HTTPR est responsable de la sauvegarde permanente et durable, dans son systeme de 
persistance, de tous les messages recus par les transactions HTTPR confirmees, avant consommation 
par les applications destinataires. 

Les messages qu'il gere sont dans les etats suivants (voir figure 18-7) : 

• regu : le message est recu dans le cadre d'une transaction confirmee et est sauvegarde ; 

• rejete : le message est recu dans le cadre d'une transaction rejetee ou annulee ; 

• incertain : le message est recu dans le cadre d'une transaction mise en doute ; 

• consomme : le message est consomme par F application destinataire et se prepare a etre « purge ». 
Letat du recepteur peut etre represente par les variables suivantes : 

• l'identifiant de la derniere transaction HTTPR recue (initialise a 0) ; 

• le statut de la derniere transaction HTTPR re5ue (initialise a « confirmee ») ; 

• l'identifiant de la derniere transaction HTTPR envoyee par l'emetteur, qui lui a ete communique 
par l'emetteur lors d'une interaction de synchronisation (initialise a 0). 




Figure 18-7 

Etats des messages chez le recepteur HTTPR. 

II est important de noter que tout lot associe a un identifiant de transaction inferieur ou egal a la 
derniere transaction envoyee doit etre rejete (transaction « en retard »). 
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Reception d'un lot de messages 

Le recepteur recoit un lot de messages emboite dans une entite HTTPR. 

Confirmation 

Si 1' entite HTTPR est correctement et entierement recue et que sa marque de fin indique qu'elle est 
valide, alors le recepteur, dans le cadre d'une transaction interne de sauvegarde : 

1. memorise l'identifiant de la transaction comme identifiant de la derniere transaction recue ; 

2. affecte le statut de la derniere transaction recue a « confirmee » ; 

3. sauvegarde les messages a l'etat « recu » et les changements d'etat en memoire secondaire. 

Apres confirmation de la transaction interne de sauvegarde, Facquittement et le statut de la transaction 
HTTPR sont retournes a l'emetteur. 

Annulation 

En revanche, en cas de reception d'un lot invalide, d'erreur de reception ou de defaillance de la 
sauvegarde, le recepteur rejette les messages, dans le cadre d'une transaction interne de rejet, et : 

1. memorise l'identifiant de la transaction comme identifiant de la derniere transaction recue ; 

2. passe le statut de la derniere transaction recue a « annulee » ; 

3. sauvegarde les changements d'etat en memoire secondaire. 

Apres confirmation de la transaction interne de rejet, Facquittement et le statut de la transaction 
HTTPR sont retournes a l'emetteur. 

Mise en doute 

Dans des cas particuliers d'incertitude sur Tissue de la transaction interne de sauvegarde, le recepteur 
retourne un acquittement avec statut « mise en doute » pour la transaction. Ce retour arrete les echan- 
ges (nous sommes en presence d'une defaillance grave). La commande de synchronisation REPORT se 
charge par la suite de determiner le resultat de la transaction (confirmation ou annulation). 

Les relations entre HTTPR et le protocole de messagerie Viable 

Quelles sont les relations entre les mecanismes mis en ceuvre par HTTPR au niveau transport et les 
proprietes fonctionnelles (garantie de livraison, suppression des doublons, respect de la sequence) 
qui caracterisent les degres de fiabilite de l'echange de messages, telles que nous les avons definie 
dans la section « L'echange fiable » ? 

La garantie de livraison est une fonction realisee par le fonctionnement de base d' HTTPR : tout 
message confie par un expediteur a un emetteur HTTPR sera livre au moins une fois, ou bien HTTPR 
peut donner un compte rendu fiable de l'impossibilite de livraison. HTTPR permet egalement de 
gerer un delai d'expiration du message applicatif : l'utilisation de ce delai affaiblit evidemment la 
garantie de livraison, mais il la conserve car lorsque le delai expire sans que la transmission ait pu 
s'effectuer, l'agent peut retourner a l'application expeditrice un compte rendu fiable d'impossibilite 
de transmission. 
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La suppression des doublons est obtenue par l'astreinte de la part de F application expeditrice et de 
1' application destinataire a une discipline particuliere : elles doivent se limiter, respectivement, a 
Conner les messages seulement une fois a Femetteur HTTPR et a extraire les messages seulement 
une fois de la base du recepteur HTTPR, le fonctionnement standard du protocole se chargeant du 
reste. Cette discipline presuppose que les applications (ou le protocole de messagerie) savent gerer 
Pidentite des messages et executer les operations de sauvegarde dans la base de Femetteur et 
d' extraction de la base du recepteur dans un cadre transactionnel. HTTPR permet de vehiculer un 
identifiant de message produit par 1' application expeditrice comme metadonnee dans la structure du 
conteneur du message applicatif. 

Le respect de la sequence est obtenu par la capacite des bases des messages de Femetteur et du recep- 
teur de gerer des files FIFO (first in, first out) pour traduire la sequence temporelle des messages en une 
liste ordonnee persistante, ainsi que par la capacite du protocole de garder Fordre dans la transmission 
des lots des messages. Cela est en principe rendu possible par F implementation du systeme de sauve- 
garde des messages, mais ce n'est pas une exigence clairement exprimee dans la specification HTTPR. 

Si le respect de la sequence temporelle n'est pas une contrainte, il est avantageux d'utiliser entre deux 
applications plusieurs canaux en parallele ou bien de gerer des priorites de messages (sequence dynami- 
que des messages). Le protocole HTTPR pourra toujours assurer la livraison « exactement une fois ou 
pas du tout ». 



Tableau (non exhaustif) des metadonnees dans le conteneur du message applicatif 



cl ass-of-service 


Valeurs : datagram (au plus une fois), rel iable (au moins une fois), assured (exactement une fois) 


message-id 


Identifiant du message fourni par I'application expeditrice 


put-time 


Date de « creation » au format UTC 


expiry 


Delai d'expiration en secondes 


priority 


Valeur de type entier. Les agents HTTPR doivent produire leur meilleur effort pour transmettre les messa- 
ges dans I'ordre de la priorite 


correl ation-id 


Identifiant du message correle (exemple : la requete si le message est une reponse) 



Degres et fonctions de fiabilite de lechange 



^"^^^^ Fonction Garantie de livraison Suppression des Respect de la sequence 

^"^-^^^ (fonctionnement de base doublons (discipline applicative 

^"^^^^^ du protocole) (discipline applicative) + gestion de file HTTPR) 
Degre ~~^^^^ 


Partiellement fiable 

(au plus une fois) 

cl ass-of-service: datagram 


NON 


OUI 


NON 


Partiellement fiable 
(au moins une fois) 
cl ass-of-service: reliable 


OUI 


NON 


NON 


Fiable 

(exactement une fois) 

class-of-service: assured 


OUI 


OUI 


NON 
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Degres et fonctions de fiabilite de I'echange (suite) 



^^^^^^ Fonction 


Garantie de livraison 


Suppression des 


Respect de la sequence 


^^^^^^ 


(fonctionnement de base 


doublons 


(discipline applicative 


^^^^^^ 


du protocole) 


(discipline applicative) 


+ gestion de file HTTPR) 


Degre 








Totalement fiable 


OUI 


OUI 


OUI 


(exactement une fois et en sequence) 








class-of-service: assured 








Totalement fiable avec priorite 


OUI 


OUI 


OUI 


(exactement une fois et en sequence 






(avec utilisation de priority) 


dynamique) 








Class-of-service: assured 









Quelques schemas d'applications d'HTTPR 

Nous pouvons maintenant illustrer 1' application d'HTTPR aux styles d'echange SOAP. Nous pren- 
drons en consideration le style requete/reponse, dans les variantes synchrone et asynchrone et le 
message a sens unique. 

La requete/reponse pseudo-synchrone 

SOAP 1.1 propose deux variantes du style d'echange requete/reponse : le style « RPC » et le style 
document. Les differences entre ces deux styles sont a rechercher dans le format du message et n'ont 
pas d'impact sur le sujet qui nous occupe. La specification SOAP 1.1 ne specifie rien quant au mode 
synchrone ou asynchrone d' execution des echanges. 

En revanche, la liaison SOAP/HTTP impose deux traits importants de la mise en ceuvre du style 
requete/reponse : 

• I'echange est synchrone, car il s'appuie sur le synchronisme de la requete/reponse HTTP ; 

• la correlation entre requete et reponse SOAP est assuree directement par le protocole de transport 
HTTP, et non par des annotations dans les en-tetes des messages eux-memes. 

La requete/reponse synchrone SOAP sur la liaison HTTP est aujourd'hui le style le plus repandu pour 
les services Web, en termes d' implementation dans les outils et d'utilisation dans les applications. 

La quasi-totalite des applications accessibles par navigateur sur le Web (et naturellement candidates 
a la mise en ceuvre en tant que services Web), ainsi qu'une grande partie des applications patrimonia- 
les que les entreprises et les administrations ont interet a exposer comme des services Web, presen- 
tent aujourd'hui une interface programmatique synchrone de type appel de procedure. Ni ces appli- 
cations existantes, ni les applications « clientes » potentielles ne sont cogues pour prendre en 
compte les dysfonctionnements et les defaillances qui peuvent surgir dans une architecture repartie et 
dont nous avons par ailleurs donne un apercu en debut de chapitre. 

L'echange avec les applications Web accessibles par navigateur est pilote par les acteurs humains, qui 
sont generalement capables de fake face efficacement aux erreurs et aux defaillances, y compris 
parfois a celles qu'ils rencontrent pour la premiere fois. Une experience meme limitee de navigation 
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sur le Web nous permet d'apprecier le nombre tres eleve de situations d'erreur que nous rencontrons 
et que nous resolvons, parfois meme sans que nous ne nous en rendions compte. 

Le remplacement de l'acteur humain par un agent logiciel est possible si ce dernier est capable de 
traiter « automatiquement » au moins une partie de ces defaillances (les plus courantes) en laissant le 
traitement des autres defaillances a 1' intervention « manuelle ». 

Un marche potentiel important pour les infrastructures d' echange fiabilise est done celui des applica- 
tions patrimoniales a interface synchrone. L'objectif est de mettre en ceuvre un echange interapplications, 
sans pour autant devoir modifier en profondeur la logique applicative. 

Nous allons verifier la possibilite theorique de fiabiliser, avec HTTPR, F echange avec ce type 
d' applications, sans etre cependant oblige de modifier : 

• le mode d' interaction par requete/reponse synchrone ; 

• les messages SOAP tels qu'ils sont generes par les outils d'aujourd'hui : Fidee est que le meme 
couple requete/reponse SOAP, qui est echange aujourd'hui en mode non fiable sur le protocole 
HTTP « pur », puisse etre echange demain en mode totalement fiable sur HTTPR ; 

• la logique applicative pour prendre en compte, au niveau application, les defaillances de F echange. 

Cela est tout a fait envisageable si une discipline appropriee et un pilotage pertinent des agents 
HTTPR (client et serveur) sont mis en ceuvre. 

Cette discipline peut se synthetiser ainsi : pour un couple d' applications (client et serveur) situe sur le 
meme canal, les requetes sont consommees par F application serveur dans Fordre de leur production 
par F application cliente et la production d'une requete est toujours successive a la consommation de 
la reponse correlee a la requete immediatement precedente. 

La premiere consequence de cette discipline est que les lots HTTPR contiennent un et un seul 
message (requete ou reponse) pour chaque couple d'applications. En revanche, ils peuvent contenir 
autant de messages qu'il y a de couples d'applications actives sur le canal. Par simplification, dans la 
discussion qui suit nous allons considerer que les serveurs HTTPR travaillent pour un seul couple 
client/serveur et done que les lots echanges sur le canal contiennent a chaque fois au plus un seul 
message. 

La discipline enoncee ci-avant fait en sorte que le protocole de transport assure la correlation des 
requetes et des reponses, sans prevoir de mecanisme explicite de correlation au niveau message. 

Par ailleurs, nous pouvons imaginer que la ligne d'execution de F application cliente envoie la requete 
au moyen d'un appel de procedure, bloquant et synchrone, au client HTTPR et obtient la reponse 
correlee par le retour d' appel. 

Le graphe de sequence de la mise en ceuvre du protocole synchrone est illustre figure 18-8. Les 
rectangles, presentes dans cette figure et dans les figures suivantes, doivent etre interpretes de la facon 
suivante : 

• Les rectangles blancs a bord noir encadrent les transactions internes aux agents HTTPR. 

• Les rectangles gris encadrent des transactions « reparties » auxquelles participent ensemble 
Fapplication et Fagent HTTPR : les etats conjoints de chaque couple (application cliente/client 
HTTPR et application serveur/serveur HTTPR) evoluent done dans un cadre transactionnel. 
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Cette gestion transactionnelle peut etre eventuellement mise en ceuvre par un protocole de 
confirmation en deux etapes. 

• Les autres actions du graphe, et notamment les transferts sur le reseau, ne sont pas gerees dans le 
cadre de transactions. 

Mise en oeuvre avec PUSH/PULL 

La requete (REQUETE) est produite par 1' application cliente et passee au client HTTPR en argument 
d'un appel de procedure. La ligne d'execution de l'application se met en attente du retour de l'appel 
qui vehicule la reponse (REPONSE) comme resultat. Le client HTTPR execute la transaction interne 
de sauvegarde de la requete. 

Des confirmation, la requete, en etat « produit », est prete a faire Fobjet d'un transfert fiable vers le 
serveur HTTPR. Le client HTTPR enchaine avec la transaction de preparation du transfert de la 
requete via la commande PUSH. La requete est emboitee dans un lot a un seul message dote d'un iden- 
tifiant de transaction HTTPR et passe a l'etat « emis ». Lorsque la transaction interne de preparation 
est confirmee, le client HTTPR emet une requete HTTPR PUSH contenant, avec la requete, l'acquittement 
de la reponse correlee a la requete precedente. 

Le serveur HTTPR recoit la requete HTTPR valide sans constater de dysfonctionnements reseau. 
Dans le cadre d'une transaction interne, le serveur sauvegarde la requete dans son systeme de persis- 
tance a l'etat « recu », ainsi que l'etat de la reponse precedente, qui ne peut etre que « confirmee » : 
en effet, selon la discipline applicative fixee, une requete ne peut etre transmise si la reponse correlee 
a la requete immediatement precedente n'est pas consommee. En cas d'erreur de reception de la 
reponse precedente, le client HTTPR emet la commande de synchronisation REPORT. A la confirma- 
tion de la transaction, la requete est sauvegardee dans l'etat « recu » et prete a etre consommee par 
l'application serveur. 

Le serveur HTTPR envoie la reponse HTTPR contenant l'acquittement de la requete avec statut 
« confirmee ». Lors de la reception de l'acquittement, le client HTTPR peut legitimement faire passer 
l'etat de la requete d'« emis » a « remis » et le sauvegarder. 

A cette etape, le serveur HTTPR et l'application serveur peuvent gerer dans le cadre d'une seule et 
unique transaction (eventuellement repartie avec confirmation en deux etapes) l'ensemble des operations 
suivantes : 

• le changement d'etat de la requete, de l'etat « recu » a l'etat « consomme » ; 

• V extraction de la requete (REQUETE) du systeme de persistance du serveur HTTPR pour l'appli- 
cation serveur ; 

• F execution d'un traitement applicatif de nature transactionnelle (dans notre exemple, la reservation 
d'une place d' avion) avec mise a jour de la base de donnees metier ; 

• la production de la reponse (REPONSE) ; 

• la sauvegarde de la reponse dans le systeme de persistance du serveur HTTPR a l'etat « produit ». 

Cet ensemble d'operations implique au moins l'existence de trois bases de donnees « logiques » : la 
base des requetes, la base de donnees metier et la base des reponses. Si les bases logiques sont mises 
en ceuvre sur des ressources physiques differentes et reparties, le protocole de confirmation en deux 
etapes s'impose. 
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Figure 18-8 

Requete/reponse pseudo-synchrone fiable avec HTTPR PUSH/PULL. 
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II y a plusieurs avantages a executer l'ensemble de ces operations dans le cadre d'une transaction : 

• Si la transaction echoue pour une raison quelconque (par exemple : la base des reponses est 
pleine), elle est annulee et done tout revient a l'etat initial. La requete reste dans la file persistante 
a l'etat « recu » et la transaction va se redeclencher automatiquement. Nous rappelons qu'il est ici 
question d'un echec technique de la transaction et non d'un echec applicatif de la reservation de 
place (par exemple : 1' avion est plein), qui peut etre le resultat d'une transaction reussie et 
confirmee ! 

• Si le serveur (soit les deux composants : serveur HTTPR et application serveur) tombe en panne 
franche au milieu de la transaction, les procedures de redemarrage pourront restaurer un etat 
correct avant execution de la transaction et le systeme se retrouvera dans l'etat initial. 

Le retour de la reponse vers 1' application cliente se passe selon les memes principes, la seule diffe- 
rence etant que l'initiative revient toujours, par construction du protocole, au client HTTPR (requete 
PULL). Cette difference peut amener a se poser la question du moment ou le client HTTPR doit emet- 
tre la requete HTTPR PULL. II s'agit d'une « fausse question » : en fait, le client HTTPR, des lors qu'il 
a recu la reponse a la requete HTTPR PUSH initiale et sauvegarde l'etat de la requete (REQUETE), 
peut emettre immediatement une requete HTTPR PULL, car il n'a plus rien a faire mis a part attendre 
la reponse (REPONSE) du serveur. 

Par ailleurs, avec un reglage adapte des parametres du vecteur des capacites, il est possible d'engen- 
drer un comportement qui peut etre decrit de la facon suivante : s'il n'y a pas de message (pour le 
canal) dans la file de sortie, le serveur HTTPR se met en attente indefinie (le plus longtemps possi- 
ble), mais des qu'il y a un message (REPONSE), il renvoie au client immediatement le lot constitue 
de ce seul message dans la reponse HTTPR. S'il y a depassement du delai d' attente maximal, le 
serveur renvoie un lot vide (la reponse n'est pas arrivee), et le client emet immediatement une requete 
PULL (ou plus simplement, la requete HTTP sort en timeout et le client 1'emet a nouveau). Cette 
technique, dite de la « requete pendante » (pending request), est utilisee pour minimiser le polling et 
le trafic reseau lorsqu'un client HTTP est en attente d'information de la part du serveur. 

L'acquittement de REPONSE de la part du client ne peut pas etre obtenu de facon synchrone, en 
raison de la construction du protocole HTTPR, et le serveur HTTPR est done dans un etat d'incerti- 
tude qui ne peut etre leve qu'a l'initiative du client HTTPR. Le fonctionnement « normal » est le 
suivant : la prochaine requete du client (qui peut etre une commande de synchronisation s'il n'y a pas 
de requete applicative apres un certain laps de temps) transporte l'acquittement et Tissue de la 
reponse precedente. En realite, a cause de la discipline imposee, la simple reception de la requete 
PUSH suivante fonctionne comme un acquittement implicite non seulement de la reception reussie de 
la reponse precedente de la part du client HTTPR, mais aussi de la consommation de la reponse de la 
part de 1' application cliente. 

Les avantages de ce modele pour 1' application cliente sont que : 

• le paradigme intuitif de la requete/reponse synchrone est conserve avec la gestion de la fiabilite des 
echanges ; 

• la logique applicative n'est pas confronted a la problematique de la fiabilite de l'echange. 

L'avantage de ce modele permet aux services distants (F application serveur) de mettre en ceuvre une 
gestion transactionnelle integree qui garantit la performance et la montee en charge. II s'agit d'une 
mise en ceuvre au niveau de l'infrastructure qui n'a que peu d'incidence sur la logique applicative. 
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La duree de verrouillage des ressources (les bases de donnees) est minimisee car le cadre transaction- 
nel ne comprend pas les echanges sur le reseau, dont le temps de latence est par definition impredictible. 

C'est a cause de Finterface pseudo-synchrone que l'application cliente ne peutpas travailler dans un 
cadre transactionnel, sauf si le cadre transactionnel synchrone est etendu a la totalite des traitements, 
par la mise en ceuvre d'une veritable transaction synchrone repartie, avec protocole de confirmation 
en deux etapes. L'approche de la transaction synchrone repartie globale presente deux inconvenients 
majeurs : 

• le couplage fort entre applications participantes induit par le protocole synchrone de confirmation 
en deux etapes (F architecture globale a un niveau de fiabilite inferieur a celui du plus faible des 
participants) ; 

• l'inclusion dans le cadre transactionnel des echanges reseau, dont le temps de latence est impre- 
dictible. 

L'effet conjoint de ces deux inconvenients peut engendrer un delai tres long de verrouillage des 
ressources critiques, avec tout ce qui s'ensuit en termes de performance. 

L' architecture de la requete/reponse pseudo-synchrone fiable est malgre tout sensible a un certain 
nombre de defaillances. La premiere d'entre elles est la panne franche du client, entre la production 
de la requete et la consommation de la reponse. En Fabsence d'une gestion transactionnelle, apres 
redemarrage, l'application cliente a perdu toute information sur la requete qu'elle a emise et doit 
done pouvoir se resynchroniser avec le client HTTPR et consommer une reponse qui ne correspond a 
aucune requete connue. 

Par ailleurs, l'appel de la pail de l'application cliente au client HTTPR est evidemment dote d'un 
delai d'attente de renvoi a ne pas depasser. En cas de depassement, il faut que l'application cliente 
puisse inspecter Fetat de la requete/reponse en cours, ce qui entraine une complexification de la logi- 
que applicative que la gestion de Fechange fiable veut justement eviter. On peut evidemment regler 
le delai d'attente a une valeur elevee, ce qui permet le rattrapage automatique par le protocole de la 
majorite des defaillances temporaires. Les cas qui restent peuvent etre regies par des procedures 
« manuelles » de reparation de ces situations. La possibilite d'inspection et d' intervention par des 
acteurs humains au niveau applicatif, via une interface homme/machine adequate, est de toute facon 
indispensable a la mise en ceuvre de ce type de systeme reparti. 

Le message a sens unique 

La mise en ceuvre du style d'echange message a sens unique fiable est particulierement simple et 
elegante avec HTTPR. 

Dans le diagramme de sequence presente figure 18-9, nous faisons l'hypothese que l'application 
emettrice insere la production du message dans le contexte d'une unite de travail transactionnelle (la 
transaction Q). 

En effet, la gestion transactionnelle jointe a la gestion de Fechange fiable permet d'effectuer la jour- 
nalisation de Facte avant meme que Facte ne soit accompli. Si la journalisation echoue, la transaction 
est annulee avec la sauvegarde du message dans la base de sortie. Si elle reussit, ainsi que les autres 
traitements applicatifs et la sauvegarde, alors le changement d'etat est permanent et durable et l'effet 
de bord associe (la transmission du message) sera realise de facon totalement fiable (une fois et 
seulement une fois dans Fordre, ou pas du tout). 
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En revanche, en raison de l'asynchronie du mecanisme, il est impossible de garantir le respect d'une 
contrainte temps reel, c'est-a-dire de garantir que la transmission du message sera effectuee dans un 
laps de temps etabli a l'avance, meme si cet effet peut etre statistiquement obtenu par le reglage des 
performances. 
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Figure 18-9 

Message a sens unique fiable avec HTTPR. 

Cette architecture garantit non seulement les conditions techniques du succes de Facte de communica- 
tion, c'est-a-dire le fait que le message est sauvegarde dans la file persistante du serveur HTTPR du 
recepteur et done ordonnance pour transmission, mais aussi les conditions techniques de sa. satisfaction, 
c'est-a-dire le fait que les traitements, consequences attendues de la reception de Facte, sont effective- 
ment executes. La transaction Q associe, dans un seul cadre trans actionnel, la consommation du 
message et les traitements applicatifs declenches par cette consommation. Cela veut dire que, si ces trai- 
tements echouent, la transaction entiere est annulee, le systeme revient a Fetat avant consommation du 
message et l'execution de la transaction est a nouveau ordonnancee. A partir du moment ou le message 
est place dans la file de sortie du client HTTPR, les conditions techniques du succes et de satisfaction de 
Facte de communication associe sont accomplies. L' architecture d'echange illustree figure 18-9 est 
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totalement fiable et garantit que la sequence de consommation est identique a la sequence de production 
des messages. 

La requete/reponse asynchrone 

La figure 18-10 presente un schema dans lequel les mecanismes illustres dans le schema du message 
a sens unique fiable sont etendus a la requete/reponse pour obtenir un style d'echange requete/ 
reponse asynchrone fiable. Ce modele resoud les problemes de fiabilite qui persistent pour la requete/ 
reponse synchrone et offre les avantages de performance des modeles asynchrones, comme la possi- 
bilite d' organisation des traitements par lots et en parallele. 

Nous allons presenter le modele dans sa version la plus simple, ou F application cliente effectue les 
requetes en sequence et ou une nouvelle requete est toujours precedee par le traitement de la reponse 
a la requete immediatement precedente. Nous allons utiliser ce schema dans le meme cas de figure 
que le schema de la requete/reponse pseudo-synchrone, pour montrer les differences ayant trait a la 
fiabilite de l'echange. 

Dans cet exemple, la commande EXCHANGE est utilisee a la place de la sequence PUSH/PULL. Le gain, qui 
peut etre important dans les applications a haut debit, vient du fait qu'une seule requete HTTP est 
executee au lieu de deux par cycle de requete/reponse avec la sequence PUSH/PULL. Naturellement, si la 
reponse HTTPR transporte un lot de messages vides (elle est partie avant la production de la reponse de 
la part de Fapplication serveur), le client doit immediatement poser une nouvelle requete HTTPR PULL. 

La transaction O reunit dans une unite de travail transactionnelle le traitement applicatif prealable a 
la requete, qui peut comprendre la mise a jour de la base de donnees metier, la production de la 
requete et la sauvegarde de la requete dans le systeme de persistance du client HTTPR. 

La transaction Q reunit dans la meme unite de travail la preparation a la consommation de la requete, 
son extraction du systeme de persistance du serveur, le traitement applicatif qui peut comporter des 
operations de mise a jour de bases de donnees metier, la production de la reponse et sa sauvegarde 
dans le systeme de persistance du serveur HTTPR. 

La transaction reunit dans la meme unite de travail la preparation a la consommation de la reponse, 
son extraction du systeme de persistance du client ainsi que le post-traitement, qui peut comprendre 
la mise a jour de la base de donnees metier. 

Entre ces transactions, les remises de messages sont gerees directement par HTTPR, toujours selon le 
meme schema : 

1. entourer le transfert du message par des transactions internes de preparation du message chez 
l'emetteur et de sauvegarde du message chez le recepteur ; 

2. retourner l'acquittement et le resultat de la remise a l'emetteur et le faire suivre par une transaction 
interne de consolidation du resultat chez l'emetteur. 

La combinaison de la mise en ceuvre de la gestion de l'echange fiable au niveau transport avec la mise 
en ceuvre d'une gestion transactionnelle chez les applications cliente et serveur, integrant les opera- 
tions en amont et en aval de sauvegarde et extraction des messages des systemes de persistance 
HTTPR, permet la mise en ceuvre d'un style d'echange requete/reponse entre applications reparties 
totalement fiable, avec comme seule modification de la logique applicative, l'encadrement transac- 
tionnel des traitements metier avec la gestion de la persistance des messages. 
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Figure 18-10 

Requete/reponse asynchrone fiable avec HTTPR. 
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Conclusion 



HTTPR est une approche virtuellement interoperable de gestion de l'echange flable au niveau trans- 
port, qui peut etre utilisee par les technologies de services Web. La prise en compte de la fiabilite au 
niveau transport permet la transparence vis-a-vis d'une partie importante des applications patrimo- 
niales et des services Web qui presentent des interfaces requete/reponse synchrones. Elle permet 
egalement des optimisations de performance via le transfert par lots de messages, le transfert par 
tranches des lots et des messages, le transfert en pipe-line, les chaines d'acheminement HTTP et la 
gestion de la securite avec SSL. 

Une lacune importante dans cette approche vient de 1' absence de prise en compte explicite des pieces 
jointes avec les messages SOAP. Lintegration d'objets MIME (multipart/related) ou DIME, qui 
permettrait la mise en ceuvre respectivement de SOAP Messages with Attachments et WS -Attachment, 
n'est pas explicitement prevue par la specification, meme si l'integration d'un message multipart/ 
rel ated dans une structure de message HTTPR devrait etre possible. 

Une approche comme HTTPR n'a de chances de s'imposer sur grande echelle que si elle est prise en 
main par un organisme comme 1TETF (Internet Engineering Task Force). Elle pourrait alors se trans- 
former en une extension fiable du protocole HTTP, ce qui en meme temps pourrait combler ses lacunes 
et permettrait ainsi une large diffusion et, a terme, sa banalisation. 

WS-Reliability 

Le 9 Janvier 2003, Sonic Software, avec d'autres compagnies comme Fujitsu, Hitachi, NEC, Oracle 
et Sun Microsystems, publient une proposition de specification de fiabilite : WS-Reliability 1.0 (http:/ 
/www.sonicsoftware.com/docs/ws_reliability.pdf), qui repose sur une extension standard de SOAP 1.1. 



Vocabulaires XML et prefixes 

Par la suite, nous utiliserons les vocabulaires XML et prefixes suivants, tires des exemples WS-Reliability : 

- pour les elements et attributs WS-Reliability : http://schemas.fujitsu.com/rm (prefixe RM) ; 

- pour I'enveloppe SOAP 1.1 : http://schemas.xmlsoap.org/soap/envelope/ (prefixe SOAP) ; 

- pour XML Schema : http://www.w3.org/2001/XMLSchema (prefixe xsd). 



Presentation generate 

Lobjectif de WS-Reliability est la prise en compte de la fiabilite de l'echange au niveau message. Le 
constat de depart est que la simple liaison SOAP/HTTP n'est pas suffisante lorsqu'un protocole de 
message au niveau applicatif doit aussi se conformer a des contraintes de securite et de fiabilite. 
Tandis que la securite est prise en compte dans un processus de specification et d'implementation 
bien etabli (WS-Security), il faut bien constater que la gestion de la fiabilite est pour l'instant delais- 
see. L' ambition affichee de WS-Reliability est de constituer une proposition initiale qui permette de 
demarrer un processus de specification et d'implementation du meme type que WS-Security. La 
specification reprend en partie des travaux precedents, effectues dans le cadre de la specification 
OASIS ebXML Message Service, et propose les modifications necessaires a une integration dans la 
technologie des services Web. 
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Portee de la specification 

La specification est une extension standard de SOAP 1.1. Comme toute extension standard, elle se 
sert d' entrees de l'en-tete SOAP 1.1, ainsi que d'elements a inserer dans le message d'erreur 
SOAP 1.1 (SOAP:Fault/detail). 

La specification ne couvre pas tous les aspects de la messagerie fiable. Notamment, elle ne donne pas 
de reponses aux questions suivantes : 

• II n'est pas necessaire ni approprie d'imposer des contraintes de fiabilite de l'echange a toutes les 
applications et a tous les services Web. Ainsi, le contrat de service (a savoir un document WSDL) 
qui inclut l'utilisation du protocole fiable doit-il expliciter les elements de qualite de service, non 
seulement qualitatifs, mais aussi quantitatifs (comme la taille maximale des bases de messages, la 
duree maximale du laps de temps consacre aux essais de transfert en cas de defaillance, etc.) ? 

• Au-dela des caracteristiques specifiques de la remise des messages (garantie de livraison, suppres- 
sion des doublons, respect de la sequence), la fiabilite doit-elle definir les moyens de synchronisa- 
tion et de negotiation entre emetteur et recepteur (avec l'objectif qu'ils aient une vue partagee de 
l'etat exact du processus de remise d'un message) ? 

Les limites de la specification ne decoulent pas d'une attitude de principe des auteurs, mais plutot 
d'un constat factuel. Ces points sont evoques comme des questions ouvertes. 

Fonctions du protocole de messagerie fiable 

La specification se situe au niveau message (SOAP) et porte uniquement sur le style d'echange 
message a sens unique (qui est appele de facon un peu pompeuse « protocole de messagerie asyn- 
chrone »). Elle s'attaque a mettre en ceuvre les trois proprietes fonctionnelles de la fiabilite de 
l'echange des messages (voir la section « L'echange fiable ») : 

• la garantie de livraison ; 

• la suppression des doublons ; 

• le respect de la sequence. 

Sujets non traites 

Certains sujets sont volontairement exclus de la specification : 

• Le style d'echange requete/reponse : il s'agit d'une omission importante, qui est de toute evidence la 
consequence de l'heritage des specifications OASIS/ebXML Message Service. La mise en ceuvre 
d'un style requete/reponse sur SOAP WS-Reliability demande soit une extension ulterieure de la 
specification afin de prendre en compte la correlation entre requete et reponse au niveau des identi- 
fiants de messages, soit un protocole applicatif qui garantit la sequence stricte des requetes et l'inter- 
diction d'emettre une nouvelle requete si la reponse a la requete precedente n'a pas ete recue. 

• Les chaines d'acheminement : les auteurs considerent que le sujet doit etre traite dans le cadre 
d'une synergie avec le developpement de technologies specifiques aux chaines d'acheminement 
(WS-Routing ?). 

• La securite : les auteurs declarent que le sujet sera traite dans le futur en synergie avec le develop- 
pement de technologies specifiques (WS-Security ?). 
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Le modele 



Le graphe de sequence SOAP WS-Reliability est presente figure 18-11. 

L' application expeditrice produit un message a sens unique, qu'elle confie a Femetteur SOAP WS- 
Reliability. Celui-ci sauvegarde d'abord le message dans son systeme de persistance puis le transmet 
au recepteur SOAP WS-Reliability, lequel sauvegarde le message dans son propre systeme de persis- 
tance apres reception reussie. Ensuite, le recepteur transmet Faccuse de reception a Femetteur, avec 
une reference a Fidentifiant du message et rend le message disponible pour consommation par 
F application destinataire. Apres reception de Faccuse de reception, le message peut etre purge du 
systeme de persistance de Femetteur. En revanche, il reste pour un laps de temps indetermine dans le 
systeme de persistance du recepteur. 
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Figure 18-11 

Modele WS-Reliability. 



La specification precise un certain nombre de situations d'erreur, dans lesquelles le recepteur, apres 
reception et analyse, transmet a Femetteur, a la place de Faccuse de reception, un message d'erreur 
SOAP avec, outre le code d'erreur SOAP: Client, un code d'erreur WS-Reliability dans 1' element 
detai 1 . Ces situations d'erreur se produisent lorsque le message est mal forme ou contient des erreurs 
de semantique. 
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La repetition de I'envoi 

Si l'emetteur SOAP WS-Reliability ne recoit pas d'accuse de reception, il doit alors essayer de trans- 
mettre a nouveau le meme message (identifie par la valeur de l'element RM:MessageId), jusqu'a 
l'accomplissement d'une des conditions suivantes : 

• obtention de 1' accuse de reception ; 

• atteinte du nombre maximal d'essais de transmission. 

Si, apres epuisement du nombre d'essais disponibles, l'emetteur n'obtient pas l'accuse de recep- 
tion, il considere qu'il y a echec definitif de la transmission du message. Dans ce cas, l'emetteur 
doit retourner une erreur a 1' application par un moyen de son choix (code de retour d'appel, levee 
d'une exception). 

La persistance 

L'emetteur SOAP WS-Reliability a la responsabilite de sauvegarder dans son systeme de persis- 
tance les messages que l'application expeditrice lui confie jusqu'a l'accomplissement d'une des 
conditions suivantes : 

• 1' obtention de l'accuse de reception pour les messages emis ; 

• l'echec de tous les essais de transmission et le retour d'une erreur a l'application expeditrice ; 

• le depassement de la date d'expiration du message (RM:TimeToLive). 

Le systeme de redemarrage, apres panne tranche de l'emetteur SOAP WS-Reliability, doit exploiter 
le systeme de persistance pour essayer de transmettre les messages non encore recus par le recepteur 
et qui peuvent etre emis. 

Le recepteur doit sauvegarder les messages recus dans son systeme de persistance pour un laps de 
temps indetermine, afin de : 

• les rendre disponibles a l'application destinataire meme apres panne tranche ; 

• pouvoir detecter les doublons. 

La suppression des doublons 

Le recepteur SOAP WS-Reliability doit rejeter (ne pas sauvegarder dans son systeme de persistance) 
les doublons de messages. Un doublon est un message ayant un identifiant (valeur de RM:MessageId) 
identique a celui d'un message deja recu. 

Le respect de la sequence 

WS-Reliability garantit que, pour un groupe de messages, la sequence de consommation par 
l'application destinataire suit la sequence de production de l'application expeditrice (voir 
figure 18-12). 
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Figure 18-12 

Respect de la sequence des messages. 

La specification preconise la mise en ceuvre d'un mecanisme reposant sur deux principes : 

• L' attribution aux messages du groupe d'un numero de sequence progressif (a partir de 0, sans 
trous) coherent avec l'ordre de production de la part de Femetteur SOAP WS-Reliability. 

• La capacite du recepteur SOAP WS-Reliability de reconstituer de fa§on incrementale la sequence 
des messages du groupe sur la base de la numerotation, independamment de la date de reception. 
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Seuls les messages de la sequence reconstituee par increments sont rendus disponibles pour 
1' application destinataire (avec retention dans un espace temporaire des messages recus hors 
sequence). 

Les messages et leur structure 

WS-Reliability propose trois structures SOAP pour trois types de messages : 

• le message a sens unique (Message) ; 

• 1' accuse de reception (Acknowledgment) ; 

• le message d'erreur (Fault). 

Les structures sont presentees figure 18-13. La presence des elements en gras est obligatoire, celle 
des elements en pointille est facultative. Un element peut etre obligatoire si son ascendant facultatif 
est present. 
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Figure 18-13 

Structures des messages SOAP WS-Reliability. 
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Le tableau suivant decrit synthetiquement les elements des messages SOAP WS -Reliability et leurs 
usages. 

Elements des messages SOAP WS-Reliability 



RM:MessageHeader 
Entree de I'en-tete SOAP. 
Obligatoire pour tout type de message. 
SOAP:mustUnderstand="l" 



RM:From 

RM:To 

RM:Service 

RM:MessageId 

RM:Timestamp 

RM:Rel iableMessage 
Entree de I'en-tete SOAP. 
Obligatoire pour le type Message. 
SOAP:mustUnderstand="l" 



Optionnel, expediteur du message, peut etre un URI. 

Optionnel, expediteur du message, peut etre un URI. 

Optionnel, nom du service, peut contenir un attribut type, URI par defaut. 

Obligatoire, identifiant unique, oonforme a Messageld (IETF - RFC2822). 

Obligatoire, date de generation de I'en-tete, de type xsd:dateTime. 



RM:MessageType 


Optionnel, valeur obligatoire : Message. 


RM:ReplyTo 


Obligatoire, URL de I'expediteur (destinataire de I'accuse de reception ou du message 
d'erreur). 


RM:TimeToLi ve 


Optionnel, delai d'expiration de la validite du message, type xsd:dateTime, (UTC). 



RM:AckRequested 



RM:Dupl icate El i mi nation 



Optionnel (element vide), obligatoire pour garantir la livraison et I'ordre de sequencement 
des messages. 

Attribut synchronous, type xsd : bool ean, valeur par defaut f al se. 
synchronous="true" : I'accuse de reception doit etre retourne de fagon synchrone. 
synchronous = "fal se" : I'accuse de reception doit etre retourne de facon asynchrone. 

Optionnel (element vide), obligatoire pour eliminer les doublons, obligatoire lorsqu'il faut 
garantir I'ordre de sequencement des messages. 



RM:MessageOrder 

Entree de I'en-tete SOAP. 

Obligatoire pour demander I'ordre de sequencement des messages. 

RM:Rel iableMessage/RM:AckRequested et RM: Rel iabl eMessage/R 

presents. 

SOAP:mustUnderstand="l" 

RM:GroupId 



:DuplicateElimination sont obligatoirement 



RM:SequenceNumber 



Obligatoire, identifiant global, de valeur conforme a Messageld (IETF - RFC2822). 

Identifiant du groupe de messages a garantie d'ordre. 

Attributs : 

removeAfter, optionnel, type xsd:dateTime (UTC), valeur par defaut forever, date 

d'expiration de la sequence ordonnee. 

status, optionnel, valeurs Start | Continue | End, valeurpardefautContinue, pour 

respectivement debut, milieu et fin de sequence. 

Obligatoire, numero de sequence, type xsd:unsignedl_ong. 
La valeur initiale est et I'increment est 1 . 
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Elements des messages SOAP WS-Reliability (suite) 



RM: RMResponse 

Entree de I'en-tete SOAP. 

Obligatoire pour accuse de reception (Acknowl edgment) et message d'erreur (Faul t). 

SOAP:mustUnderstand="l" 


RM:MessageType Obligatoire, valeurs : Acknowledgment | Fault. 


RM:RefToMessageId Obligatoire, reference au message correle, type Messageld (IETF- RFC2822). 


RM:RMFault 

Descendant direct de SOAP: Fault /detail . 

Optionnel :si present, lavaleurde faultcode est SOAP: Client. 


RM:faultcode 


Obligatoire (si RM:RMFault est present). 

Valeurs possibles : 

RM: Inval idMessageHeader 




RM: Inval idMessageld 




RM: Inval idRefToMessageld 




RM: Inval idTimestamp 




RM: Inval idTimeToLive 




RM: Inval idRel iableMessage 




RM: Inval idAckRequested 




RM: Inval idMessageOrder 



Le tableau suivant synthetise 1' usage des elements impliques dans la definition des degres de 
fiabilite. 



Degres de fiabilite et elements du message 



Fonction 
Degre 


Garantie de livraison 

(RM:AckRequested) 


Suppression des doublons 

(RM:Dupl icateEl i mi nation) 


Respect de la sequence 

(RM:MessageOrder) 


Partiellement fiable 
(au plus une fois) 


NON 


OUI 


NON 


Partiellement fiable 
(au moins une fois) 


OUI 


NON 


NON 


Fiable 

(exactement une fois) 


OUI 


OUI 


NON 


Totalement fiable 
(exactement une fois et 
en sequence) 


OUI 


OUI 


OUI 


Totalement fiable 
avec priorite 
(exactement une fois et 
en sequence dynamique) 


OUI 


OUI 


NON 

(pas de gestion 

de priorites) 
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Quelques exemples 

Les exemples sont tires directement de la specification. 

Message a sens unique SOAP WS-Reliability 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP:Envelope 
xmlns:SOAP=" http://schemas.xml soap.org/soap/envelope/" 
SOAP:encodingStyle="http: / /schema s.xml soap.org/soap/encoding/"> 
<SOAP:Header> 
<RM:MessageHeader xmlns: RM=" http://schemas.fuj itsu.com/rm" 
SOAP: must Under stand="l"> 
<RM: From>requestor@anyuri .com</RM: From> 
<RM:To>responder@someuri .com</RM:To> 
<RM:Service>urn: services: ItemQuoteService</RM:Service> 
<RM:MessageId>20020907-12-34@anyuri.com</RM:MessageId> 
<RM:Timestamp>2002-09-07T10:19:07</RM:Timestamp> 
</RM:MessageHeader> 

<RM: Rel iableMessage xmlns:RM=" http://schemas.fujitsu.com/rm" 
SOAP: must Under stand="l"> 
<RM:MessageType>Message</RM:MessageType> 
<RM:ReplyTo>http://serverl.anyuri .com/service/</RM:ReplyTo> 
<RM:TimeToLive>2002-09-14T10:19:00</RM:TimeToLive> 
<RM:AckRequested SOAP:mustUnderstand="l" synchronous="fal se"/> 
<RM:Dupl icateEl imination/> 
</RM:ReliableMessage> 

<RM:MessageOrder xmlns: RM="http://schemas. fujitsu.com/rm" 
SOAP: must Under stand="l"> 

<RM:GroupId status="Continue">020907-45261-0450@a.com</RM:GroupId> 
<RM:SequenceNumber>12</RM:SequenceNumber> 
</RM:MessageOrder> 
</SOAP:Header> 
<S0AP:Body> 
<gip:GetItemPrice xmlns :gip="Some-URI"> 

<gip:itemnumber>productl2345</gip:itemnumber> 
</gip:GetItemPrice> 
</S0AP:Body> 
</SOAP:Envelope> 

Accuse de reception SOAP WS-Reliability 

<?xml version="1.0" encoding="UTF-8"?> 
<SOAP:Envelope 
xmlns :S0AP=" http://schemas.xml soap.org/soap/envelope/" 
SOAP :encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 
<SOAP:Header> 
<RM:MessageHeader xmlns : RM=" http://schemas.fuj itsu.com/rm" 
SOAP:mustUnderstand="l"> 
<RM: From>responder@someuri .com</RM:From> 
<RM:To>requester@anyuri .com</RM:To> 
<RM:Service>urn: services: ItemFil ingService</RM:Service> 
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<RM:MessageId>20020907-045261-0450@someuri.com</RM:MessageId> 
<RM:Timestamp>2002-09-07T10:19:07</RM:Timestamp> 
</RM:MessageHeader> 

<RM: RMResponse xml ns:RM= "http://schemas.fujitsu.com/rm" 
SOAP:mustUnderstand="l"> 

< RM: Mess ageType>Acknowledgment</RM: Mess ageType> 
<RM:RefToMessageId>20020907-12-34@anyuri.com</RM:RefToMessageId> 
</RM:RMResponse> 
</SOAP:Header> 
<S0AP:Body> 
</S0AP:Body> 
</SOAP:Envelope> 

Message d'erreur SOAP WS-Reliability 

<?xml version="1.0" encoding="UTF-8"?> 

<S0AP: Envelope xml ns:S0AP=" http://schemas.xml soap. org/ soap/envelope/" 
SOAP :encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 
<SOAP:Header> 
<RM:MessageHeader xml ns:RM=" http://schemas.fuj itsu.com/rm" 
SOAP:mustllnderstand="l"> 

<RM:MessageId>20020907-045261-0450@anyuri.com</RM:MessageId> 
<RM:Timestamp>2002-09-07T10:10:07</RM:Timestamp> 
</RM:MessageHeader> 

<RM: RMResponse xml ns:RM=" http://schemas.fuj itsu.com/rm" 
SOAP:mustUnderstand="l"> 
<RM:MessageType>Fault</RM:MessageType> 

<RM:RefToMessageId>20020907-12-34@anyuri.com</RM:RefToMessageId> 
</RM:RMResponse> 
</SOAP:Header> 
<S0AP:Body> 
<SOAP:Fault> 
<faultcode>SOAP:Client</faultcode> 

<faultstring>Error in the Message Header sent from Server</faultstring> 
<detail> 
<RM: RMFaul t xml ns : RM="http: //schemas .f ujitsu. com/rm"> 
<RM:faul tcode>RM: Inval idMessageHeader</RM:faultcode> 
</RM:RMFault> 
</detail> 
</SOAP:Fault> 
</SOAP:Body> 
</SOAP:Envelope> 



La liaison SOAP WS-Reliability/HTTP 

La specification WS-Reliability definit la liaison avec le protocole de transport HTTP. 

Le message a sens unique SOAP WS-Reliability, comme tout message SOAP, est toujours vehicule 
par une requete HTTP POST. 
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Pour les accuses de reception et les messages d'erreur, deux modes de transport sont possibles : 

• Transport synchrone : les accuses de reception et les messages d'erreur sont transportes dans le 
corps de la reponse HTTP correlee a la requete HTTP qui a vehicule le message a sens unique. 
Dans ce cas, le recepteur n'a besoin que d'un serveur HTTP. 

• Transport asynchrone : les accuses de reception et les messages d'erreur sont transportes par des 
requetes HTTP POST independantes. La reponse HTTP correlee a la requete qui a achemine le 
message a sens unique est vide, de meme que la reponse HTTP correlee a la requete qui a trans- 
porte l'accuse de reception ou le message d'erreur. La correlation entre messages a sens unique et 
accuses de reception ou messages d'erreur est assuree exclusivement par les references aux iden- 
tifiants des messages propres au protocole WS -Reliability. 

Conclusion 

La specification WS-Reliability constitue de toute evidence une proposition initiale car elle presente 
beaucoup de lacunes. Des implementations precoces seraient tentees de pallier ces insuffisances par 
ce que Ton appelle des choix d' implementation, ce qui entrainerait des defauts majeurs d'interope- 
rabilite. Le probleme est que l'interoperabilite est le premier objectif d'une specification d'infrastruc- 
ture d'echange fiable. 

Les lacunes les plus importantes sont : 

• L absence d'un protocole de synchronisation et de negociation entre les participants de l'echange : 
le protocole de synchronisation est une partie indispensable du protocole d'echange fiable, notam- 
ment pourresoudre les situations d' incertitude, qui se produisent surtout lors de depassements des 
differents delais d'attente. 

• L absence d'une definition claire des elements de qualite de service, et notamment des delais 
d'attente et d'oubli : comment definit-on le laps de temps pendant lequel le recepteur doit garder la 
trace des identifiants de messages pour la suppression des doublons ? Combien de temps faut-il 
garder les messages hors sequence ? La definition de ces caracteristiques de la qualite de service 
est indispensable pour pouvoir les publier en tant qu'elements du contrat de service dans des 
documents WSDL, et pour en faire l'objet de negociation a l'execution. 

Mises a part ces lacunes, WS-Reliability est totalement liee au modele de messagerie asynchrone, ce 
qui limite fortement sa cible potentielle. Ladoption d'un modele de messagerie asynchrone demande 
aux applications qui presentent naturellement une interface synchrone des changements importants 
relatifs a la logique applicative. 

Avantages et inconvenients des deux approches 

La mise en ceuvre d'un protocole d'echange fiable au niveau transport, comme HTTPR, fait en 
sorte que le meme message SOAP qui est transmis aujourd'hui sur HTTP, puisse etre transmis 
demain sur HTTPR. La gestion des erreurs reste encore cloisonnee : un message d'erreur SOAP 
est transmis par HTTPR comme tout autre message SOAP et une situation d'erreur HTTPR est 
traitee au niveau HTTPR. En conclusion, le message SOAP n'est pas affecte par la gestion de la 
fiabilite de son transport. 
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En revanche, la transmission du meme message applicatif (le meme corps SOAP) via WS-Reliability 
implique une modification de l'en-tete SOAP pour les besoins de gestion de l'echange fiable. Le trai- 
tement des erreurs fait en outre remonter des problemes d' emission, de reception et de sauvegarde 
des messages au niveau SOAP (par Fintermediaire des erreurs SOAP). 

Par ailleurs, F implementation de l'echange fiable au niveau du protocole de messagerie presente un 
avantage reciproque : le protocole de messagerie fiable peut etre mis en ceuvre sur differents protoco- 
les de transports, eventuellement non fiables. En revanche, il semble difficile et, en tout cas redondant 
et non performant, de mettre en ceuvre la liaison d'un protocole de messagerie fiable comme WS- 
Reliability sur un protocole de transport fiable, sauf si la separation de niveau entraine un partage 
clair des responsabilites. 

Du point de vue « fonctionnel », il faut noter qu'HTTPR offre la possibilite de gerer les priorites de 
messages mais ne pose pas d' exigences claires aux implementeurs quant au respect de la sequence 
temporelle. A Finverse, WS-Reliability couvre parfaitement le respect de la sequence, mais ne 
presente pas de mecanisme de gestion des priorites. 

Un point important a considerer est la transmission groupee des messages (boxcarring). Nous savons 
que le protocole SOAP, qui doit rester simple comme son nom developpe Findique, ne traite pas la 
transmission groupee des messages. Cette limite, tout a fait justifiee pour garder la simplicite du 
protocole, reste en vigueur dans toute version fiabilisee du protocole SOAP qui, comme WS-Reliabi- 
lity, est mise en ceuvre de la meme facon qu'une extension SOAP (par Futilisation des entrees de 
l'en-tete). WS-Reliability est done par construction incapable de mettre en ceuvre la transmission 
groupee, qui peut etre une exigence importante d' applications critiques a haut debit d'echange et est 
particulierement appropriee lors de Futilisation de protocoles asynchrones. 

Lorsque la gestion de l'echange fiable est assuree au niveau transport, comme pour HTTPR, cette 
contrainte saute d'elle-meme, car Funite de transmission au niveau transport n'est pas a priori le 
message SOAP individuel. Le protocole HTTPR gere la transmission groupee de lots de messages 
SOAP. 

Un dernier point touche a la gestion de pieces jointes aux messages applicatifs, qui n'est explicite- 
ment prise en consideration ni par HTTPR, ni par WS-Reliability. II s'agit d'une omission impor- 
tante : la possibilite d'associer a un message SOAP des objets de toute sorte sans operer de change - 
ments de codage qui se revelent extremement coiiteux est une fonction fondamentale du protocole 
qui ne peut pas etre sacrifiee a la fiabilite de l'echange. 

Ainsi, il est difficile de trancher et de dire si un choix doit etre effectue entre le protocole de transport 
(HTTPR) ou le protocole de message (WS-Reliability). Tout au plus peut-on se borner a emettre une 
consideration generate selon laquelle faire descendre une fonction technique dans les couches basses 
d'une architecture produit toujours une amelioration de la fiabilite et la performance. 

En conclusion, aucune des deux specifications n'a encore atteint le niveau de maturite et d' acceptation 
necessaire a une adoption large de ce type de technologie. 
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Gestion de la securite 



Ce chapitre propose, dans une premiere partie, une presentation generale des technologies d' infras- 
tructure de securite pour les services Web. Dans une deuxieme partie, il complete la description de la 
plate-forme .NET (chapitre 15) avec la gestion de la securite (WSE ou Web Service Enhance- 
ments 1.0). Dans la troisieme partie, les implementations en Java et .NET disponibles aujourd'hui 
sont utilisees pour mettre en ceuvre un cas d' utilisation simple, qui demontre egalement un niveau 
effectif d'interoperabilite entre ces implementations. 

Sur un reseau IP, deux applications reparties peuvent interagir aujourd'hui avec la garantie d'un 
niveau acceptable de securite de communication : la confidentialite des echanges, Vintegrite des 
messages et V authentification des agents participants a l'echange sont geres dans Fespace d'une 
session securisee, via l'utilisation de protocoles de securite comme SSL, TLS et eventuellement 
IPSEC (voir le chapitre 5). 



Confidentialite, integrite, authentification 

Voici les definitions de ces trois notions : 

- la confidentialite des echanges est la garantie qu'une tierce partie indelicate ne peut pas acceder au contenu 
des echanges ; 

- I'integrite des messages est la garantie que les messages ne sont pas modifies, transformes ou corrompus, de 
fagon accidentelle ou intentionnelle, sans que le recepteur ne s'en apergoive ; 

- I'authentification du message est la preuve de I'identite de I'expediteur ; 

- I'authentification des parties, en general, est la preuve de I'identite des parties (autres que I'expediteur) impli- 
quees dans l'echange. 

L'identite d'une entite (un utilisateur, une application, une machine...) est un ensemble d'attributs (qui sont censes 
decrire I'entite en question) dote d'un identifiant. 

Les proprietes de l'echange que nous venons de presenter peuvent etre gerees sur une interaction ponctuelle 
entre deux agents, ou bien s'appliquer sur une sequence d'interactions {session securisee). 
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Les protocoles de securite SSL et TLS permettent d'effectuer aujourd'hui, a partir d'un navigateur 
Web et par le biais du protocole HTTP securise, des transactions commerciales impliquant des paie- 
ments en ligne sur Internet. Dans la troisieme partie de cet ouvrage, nous avons vu que les applica- 
tions qui prennent en charge ces transactions accessibles sur un site Web peuvent aussi etre dotees 
d'une interface de service Web avec un effort minimal, a l'aide des outils et des environnements de 
developpement disponibles. Les services Web resultants presentent le meme niveau de securite que 
les sites Web eux-memes : toutes choses egales par ailleurs, la technologie de transport que ces deux 
approches utilisent est la meme, a savoir HTTP securise. 

Les technologies de securite que nous venons d'evoquer (HTTP, SSL, TLS...) permettent done de 
construire un contexte de securite dans lequel la confidentialite de l'echange, Fintegrite des messages 
et Fauthentification des agents sont garantis au niveau transport (voir figure 19-1). 

Contexte 

de 
securite 



Alice 



~^r 



Bob 



Figure 19-1 

Contexte de securite au niveau transport. 

La gestion de la securite au niveau transport est certainement necessaire aux architectures de services 
Web, mais est-elle suffisante pour mettre en ceuvre des architectures orientees services complexes sur 
Internet ? 

La reponse, en ce qui concerne la securite, est clairement negative, d'oii Fattente justifiee des utilisa- 
teurs de technologies d' infrastructure specialement concues pour la gestion de la securite de services 
Web. 

La gestion de la securite au niveau transport est bien suffisante dans les cas simples ou un site Web 
transactionnel et securise est double par un service Web. Nous nous trouvons dans la situation illus- 
tree figure 19-1, dans laquelle les messages entre Alice et Bob (personnages fetiches des exemples 
d' architectures et de protocoles de securite, qui represented deux applications reparties) sont chiffres 
et leur integrite ainsi que Fauthentification des ports sont garanties par des mecanismes de signature. 

La situation change si Farchitecture demande qu'un ou plusieurs intermediaires puissent se glisser 
entre Alice et Bob. Or, ces intermediaires, ainsi que des tierces parties, sont necessaires pour mettre 
en ceuvre des architectures plus elaborees telles que : 

• des architectures qui beneficient de services d' infrastructure technique comme la fiabilite de 
l'echange (chapitre 18) ou la gestion de transactions (presentee chapitre 20) ; 

• des architectures de processus metier interapplications, comme celles baties selon le schema 
« chaine de responsabilite » (voir plus loin). 

Dans une chaine d'acheminement, un message est emis par Fexpediteur (Alice) a destination de Bob, 
et ce message transite par un intermediaire (Carol). Cet intermediaire peut evidemment lire le 
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message, doit eventuellement en consommer une partie et/ou en produire une autre partie a l'inten- 
tion de Bob. L'intermediaire peut operer au niveau echange (SOAP) : il lit le message, consomme les 
entrees de l'en-tete qui lui sont destinees et en produit d'autres a destination de Bob, sans jamais trai- 
ter le corps. L'intermediaire peut ainsi operer au niveau application, tout en respectant la discipline 
SOAP sur les chaines d'acheminement (qui dicte que le corps du message ne peut pas etre modifie 
par un intermediaire). 

Dans le cadre d'une chaine d'acheminement, la mise en ceuvre d'un contexte de securite au niveau 
transport ne permet de gerer la securite que selon un mode point a point (voir figure 19-2). 
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Figure 19-2 

Securite point a point. 

Un contexte de securite est etabli entre Alice et l'intermediaire Carol. Un autre contexte est etabli 
entre Carol et Bob. Cette architecture ne resiste pas a une usurpation de l'identite de Carol de la part 
d'un intermediaire indelicat, ni a une attaque reussie, qui se termine par la prise en main de Carol de 
la part d'un logiciel malveillant. Apres une usurpation ou une attaque reussie, il est possible de proceder 
sans veritables obstacles a plusieurs atteintes graves de la securite : 

• la violation de la confidentialite, par mise sous ecoute des messages qui transitent, le traitement de 
ces messages restant celui qui etait prevu pour Carol ; 

• la violation de l'integrite du message, par usurpation de l'identite de Carol et le remplacement pur 
et simple du message d'origine. 

Ces operations ne sont pas si difficiles a mener, surtout si les logiciels en presence, comme les 
proxies et les skeletons, sont concus pour reagir automatiquement, en envoyant par exemple des 
accuses de reception signes, ou en dechiffrant des messages qui sont ensuite passes a des tiers en 
clair. Un certain nombre de regies generates de comportement sont mises en ceuvre : ne jamais 
signer des messages arbitraires ou inconnus, ne jamais dechiffrer des messages arbitraires et passer 
le resultat a d'autres, ne pas utiliser le meme algorithme pour le chiffrement et pour la signature. II 
n'en reste pas moins que l'attaque reussie de l'intermediaire ou l'usurpation de son identite est 
pratiquement imparable. 

La mise en ceuvre de chaines d'acheminement pose en outre des exigences d'authentification de bout 
en bout : les interventions des intermediaires sur les messages peuvent etre signees, et le destinataire 
doit pouvoir valider les signatures de tous les intervenants. 

En conclusion, la mise en ceuvre d' architectures reparties, dans lesquelles les messages peuvent 
transiter sur des chaines d'acheminement constitutes de plusieurs intermediaires, necessite 
l'etablissement d'un contexte de securite de bout en bout, c'est-a-dire du producteur/expediteur au 
destinataire/consommateur, aux niveaux echange et application (voir figure 19-3). 
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Figure 19-3 

Securite de bout en bout. 

Un exemple (voir figure 19-4) peut eclaircir cette problematique de la securite de bout en bout. Un 
expediteur (application de gestion des achats) envoie un message qui vehicule une commande. Le 
message contient une entree de l'en-tete avec un numero de commande et la description de la 
commande dans le corps. L' expediteur signe F entree de l'en-tete et le corps du message puis envoie 
le message par HTTPS (la confidentialite au niveau transport est acceptable). 
Le message est recu par F application de gestion des commandes, qui verifie et valide la signature, 
execute le traitement applicatif, insere dans le message une entree de l'en-tete avec un numero de 
livraison, signe le numero de commande et le numero de livraison et, eventuellement, le corps et 
transmet le message a F application de gestion des livraisons. 

L' application de gestion des livraisons verifie et valide les signatures et effectue le traitement appli- 
catif d'ordonnancement de la livraison. Lorsque celle-ci est accomplie, le livreur en saisit le compte 
rendu et l'application l'ajoute au message (dans une entree de l'en-tete), signe le numero et le compte 
rendu et, eventuellement, le coips du message et transmet le message a l'application de gestion des 
factures. Cette demiere verifie toutes les signatures, valide la chaine de traitement de la commande et 
execute le traitement applicatif qui declenche Femission de la facture. 

Le modele de ce processus metier est appele « chaine de responsabilite ». Dans le domaine des 
technologies des services Web, ce modele peut faire un usage intensif des entrees de l'en-tete 
SOAP. Le corps du message, qui peut etre une occurrence d'un document standardise de type 
« commande », est signe plusieurs fois mais n'est jamais modifie. Ce modele est bien adapte a des 
processus sequentiels pour lesquels la tracabilite technique et applicative ainsi que la non-repudiation 
sont des exigences importantes. 
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Figure 19-4 

Chaine de responsabilite. 



Chaine de responsabilite 

A I'origine, la chaine de responsabilite est un des modeles (patterns) de traitement present.es dans I'ouvrage de 
reference sur le sujet : E. Gamma, R. Helm, R. Johnson, J. Vissides, Design Patterns: Micro-architectures for 
Reusable Object-oriented Software, Addison Wesley, 1 994. 
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En resume, la gestion de la securite dans les architectures de services Web s'etale sur plusieurs 
niveaux de traitement (voir figure 19-5) : 

• La confidentialite, F integrite et Fauthentification du message point a point peuvent etre traitees au 
niveau transport. 

• Les memes proprietes du message peuvent etre assurees de bout en bout par une gestion de la securite 
au niveau echange. 

• La gestion generale de Fauthentification de toutes les parties impliquees dans le processus metier 
(des participants a la chaine d'acheminement et au-dela), ainsi que de leurs autorisations (droits et 
habilitations), ne peut etre effectuee qu'au niveau application. 

La technologie de securite de services Web en developpement aujourd'hui se concentre au niveau 
echange, comme une extension standard de SOAP. Cependant, comme on le verra par la suite, une 
gestion standard generale des authentifications et des autorisations figure parmi les objectifs d'une 
deuxieme phase de developpement de la technologie. 
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Figure 19-5 

Gestion de la securite par niveaux. 

Un obstacle important a la mise en ceuvre d'un contexte de securite de bout en bout dans les proces- 
sus qui impliquent des applications patrimoniales est la diversification et Fheterogeneite des appro- 
ches de securite. Alice peut utiliser comme mecanisme d' authentification une infrastructure a cle 
publique (X.509) tandis que Bob utilise un systeme a cle symetrique (exemple : Kerberos). lis 
peuvent aussi implementer des algorithmes de chiffrement et de signature differents. II se pose done 
un veritable probleme d'interoperabilite au niveau de la gestion de la securite, dont la solution au 
moindre effort (en ce qui concerne la modification des applications participantes) necessite la mise 
en ceuvre d'espaces de confiance mutualises et de tiers de confiance qui agissent comme interme- 
diaires. II faut bien noter que Finteroperabilite au niveau des approches de securite est un probleme 
d'une nature differente de celle du probleme canonique des technologies des services Web, a savoir 
Finteroperabilite entre implementations differentes de la meme specification. 

En fait, Finteroperabilite doit etre comprise au sens le plus large du terme : il ne s'agit pas seulement 
de fake cooperer des approches et des technologies de securite heterogenes, mais aussi des applications 
qui ont, fonctionnellement, des exigences de securite tres differentes comme : 

• les applications patrimoniales d'entreprise ; 
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• les nouvelles applications et les nouveaux services Web ; 

• les applications reparties dans les reseaux locaux d'entreprise, comme le travail de groupe, etc. 

A terme, dans le cadre de la mise en ceuvre d' architectures orientees services dynamiques, les parti- 
cipants doivent pouvoir exprimer leurs exigences de securite dans des clauses de leurs contrats de 
services et mettre en ceuvre une veritable strategie de securite. Cela implique, evidemment, que 
parmi les criteres de choix dynamique d'un prestataire d'un service Web figurent en bonne place les 
garanties de securite qu'il offre. 



X.509 

Le protocole X.509 fait partie de I'lSO Authentication Framework, qui repose sur le chiffrement a cle publique. C'est 
un standard ITU (International Telecommunication Union ; voir http://www.itu. int/rec/recommendation.asp?type= 
items&lang=e&parent=T-REC-X.509-200003-l). 

La specification X.509 recommande RSA et SHA, mais d'autres algorithmes de chiffrement et fonctions de 
hachage peuvent etre utilises. La partie la plus importante de la norme X.509 est la structure des certificats a cle 
publique. Chaque utilisateur (acteur humain ou agent logiciel) possede un nom unique : une autorite de certifica- 
tion emet un certificat qui contient, entre autres, le nom et la cle publique de I'utilisateur. 
Un certificat X.509 contient les donnees suivantes : 

- un numero de version (qui identifie le format du certificat) ; 

- un numero de certificat (propre a I'autorite de certification) ; 

- I'identifiant de I'algorithme utilise pour signer le certificat avec ses parametres ; 

- le nom de I'autorite de certification ; 

- I'intervalle temporel de validite ; 

- le nom du sujet certifies ; 

- la cle publique du sujet certifie ; 

- I'identifiant de I'algorithme de signature/verification a utiliser avec la cle publique du sujet certifie et ses parametres ; 

- la signature de I'autorite de certification. 

Si Alice veut communiquer avec Bob de fagon securisee, elle doit d'abord obtenir le certificat de Bob et verifier son 
authenticite. Si Alice et Bob font confiance a la meme autorite de certification, la tache peut etre tres simple : Alice 
verifie la signature de I'autorite de certification au moyen de la cle publique de cette autorite qu'elle possede par 
ailleurs. Si Bob et Alice n'utilisent pas les services de la meme autorite de certification, la tache est plus complexe 
et consiste en pratique a parcourir un chemin de confiance, c'est-a-dire a remonter un arbre d'autorites de certifi- 
cation (les autorites de certification sont a leur tour certifiees par d'autres autorites de certification) jusqu'a la 
racine du sous-arbre qui contient les autorites de certification a qui Alice et Bob font confiance, et ensuite descen- 
dre la branche de I'arbre qui conduit a Bob. 

Une fois obtenue de fagon sure la cle publique de Bob, Alice peut initier un protocole d'authentification avec Bob. 
X.509 utilise trois protocoles : one-way, two-way ou three-way (ce dernier protocole a comme avantage de ne pas 
utiliser de timestamps et done de ne pas demander la synchronisation des horloges). 
La complexite dans la gestion d'infrastructures a cle publique, dont X.509 constitue la norme principale, vient 
surtout de la gestion des certificats, qui doivent : 

- etre stockes de fagon sure ; 

- pouvoir etre revoques de fagon effective, avec prise d'effet immediate (mais evidemment gardes dans la base 
pour la tragabilite et la non-repudiation) ; 

- etre stockes au-dela de la date d'expiration (toujours pour les memes raisons de tragabilite et de non-repudiation). 
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Kerberos 

Kerberos est un protocole d'authentification congu pour les reseaux TCP/IP qui repose sur un tiers de confiance (le 
service Kerberos). Kerberos fournit une authentification sure et fiable dans le reseau qui permet a I'entite (acteur 
humain ou agent logiciel) I'acces a differents systemes. II est centre sur un algorithme de chiffrement a cle syme- 
trique (I'algorithme DES est utilise de maniere non exclusive). Le principe de Kerberos est que le serveur partage 
une cle symetrique secrete avec ses clients et la connaissance de cette cle vaut identification du client. 
Kerberos maintient une base de donnees des clients (acteurs humains et agents logiciels) et de leurs cles secre- 
tes. Grace a sa connaissance exclusive des cles secretes, le serveur Kerberos peut construire des authentifiers, a 
savoir des messages prouvant I'identite d'un client aupres d'un autre, ainsi que des cles de session, qui permettent 
a deux clients de chiffrer les messages qu'ils s'echangent. La cle de session est detruite apres usage. Une cliff i- 
culte, qui limite I'usage generalise de Kerberos, est que ce protocole demande la synchronisation des horloges des 
participants au protocole d'authentification. 

Kerberos n'est pas dans le domaine public, mais le code du MIT est accessible et plusieurs implementations sont 
disponibles. II fait I'objet depuis septembre 1993 d'une RFC (IETF RFC1510 ; http://www.ietf.org/rfc/rfc1510.txt). 

Les algorithmes les plus utilises (voir aussi chapitre 5) 

-DES : Data Encryption Standard est un algorithme de chiffrement a cle symetrique developpe par IBM sur 
demande du NBS (National Bureau of Standards) des Etats-Unis en 1974 et publie par la suite. C'est un des algo- 
rithmes les plus utilises. 

National Bureau of Standards, NBS FIPS PUB 46, Data Encryption Standard, U.S. Department of Commerce, Jan 
1977. 

-RSA : (acronyme construit a partir des noms des auteurs Rivest, Shamir et Adleman) est un algorithme de chiffre- 
ment a cle asymetrique, publie en 1978, et tres utilise aujourd'hui. Pour donner une idee generale des performan- 
ces, on considere que DES est cent fois plus performant que RSA en implementation logicielle (mille fois en 
implementation materielle). 

R.L. Rivest, A. Shamir, and L.M. Adelman, A method for Obtaining Digital Signatures and Public-Key Cryptosys- 
tems, Communications of the ACM, v. 21 , n. 2, Feb 1978, pp. 120-126. 

-SHA : Secure Hash Algorithm est un algorithme de hachage congu par le NIST (National Institute of Standards 
and Technology) des Etats-Unis, en cooperation avec la NSA (National Security Agency), a utiliser en couple avec 
un algorithme de chiffrement a cle asymetrique (notamment RSA). 

National Institute of Standards and Technology, NIST FIPS PUB 180, Secure Hash Standard, U.S. Department of 
Commerce, May 1993. 

-DSA : Digital Signature Algorithm est un algorithme de signature qui repose sur un algorithme de chiffrement a cle 
asymetrique, propose par le NIST en 1991 . II est concurrent de RSA. II utilise SHA pour le calcul du condense (digest). 
National Institute of Standards and Technology, NIST FIPS PUB 1 86, Digital Signature Standard, U.S. Department 
of Commerce, May 1994. 



Larchitecture et la roadmap de la securite pour les services 
Web 

Les principes generaux du modele d' infrastructure de la gestion de securite, adaptes a la mise en 
place a grande echelle d' architectures securisees de services Web peuvent etre resumes ainsi : 

• Les messages s'echangent sur la base d'un modele general de messagerie securisee (au niveau 
echange). Ce modele permet de mettre en ceuvre la confidentialite et l'integrite d'elements du 
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message de bout en bout. La confidentialite et l'integrite doivent pouvoir etre mises en ceuvre de 
facon independante et factorisee (par exemple, pour ce qui touche les algorithmes et les cles 
de chiffrement et de signature) sur des parties du message. La gestion de l'integrite et de la confi- 
dentialite au niveau transport doit pouvoir s'ajouter sans difficultes a la gestion de l'integrite et de 
la confidentialite au niveau echange. 

• Un agent logiciel destinataire d'un message peut exiger que le message qui arrive soit en mesure de 
vehiculer et de prouver un ensemble d' assertions (l'identite de l'envoyeur, la cle publique de 
l'envoyeur, les algorithmes de signature et de chiffrement, les droits, les habilitations, etc.). Si un 
message arrive sans les assertions demandees ou sans en apporter la preuve, ou bien si la verifica- 
tion de ces assertions echoue, le recepteur peut ou doit ignorer ou rejeter le message. L'ensemble 
des assertions dont la preuve est exigee par le destinataire s'appelle contrat de securite. Les accre- 
ditations (preuves d'identite reposant sur la confiance dans une autorite de certification) font partie 
des assertions les plus souvent demandees. 

• L'expediteur peut envoyer des messages avec les preuves des assertions demandees par 1' insertion 
dans le message d'objets appeles jetons de securite. Le message n'est plus seulement le moyen de 
transport d'un acte de communication, mais il transporte egalement la preuve que certaines condi- 
tions de reussite de Facte de communication sont accomplies (en termes, par exemple, non exclu- 
sifs, d'elements d'authentification et d'autorisation de l'expediteur, par exemple). La preuve des 
assertions transmise a l'aide d'un jeton de securite {security token) repose sur la confiance : en fait, 
le destinataire n'a pas generalement de moyens directs d'authentifier, ni eventuellement de verifier 
les droits et habilitations de l'expediteur et cette verification se fonde sur la confiance qu'il a en un 
tiers de confiance qui valide les revendications d'identite, des droits et des habilitations de l'expe- 
diteur. Au-dela de l'authentification et des autorisations, le jeton de securite peut contenir un large 
spectre d' assertions. 

• Lorsque l'expediteur ne peut pas directement prouver les assertions demandees par le destinataire, 
il peut, directement ou via un agent delegue, essayer d'obtenir la preuve de ces assertions en 
demandant a un service Web, tiers de confiance specialise {services de distribution de jetons de 
securite), les jetons de securite dont il a besoin. Ces services Web peuvent egalement exhiber leur 
contrat de securite, le modele etant recursif. Ces services tiers de confiance peuvent servir d' inter- 
mediaries de confiance entre plusieurs domaines. 

• Les implementations concretes du modele doivent non seulement pouvoir prendre en compte des 
technologies existantes et utilisees, comme les infrastructures a cle publique X.509, les modeles 
d'authentification a cle symetrique comme Kerberos, les modeles centres sur le condense {digest) 
du mot de passe, les jetons sim card, les donnees bio-metriques, etc., mais aussi les « federer », a 
savoir permettre la mise en ceuvre d' architectures reparties dans lesquelles, par exemple, des meca- 
nismes d'authentification differents sont utilises par les applications participates et les interme- 
diaires tiers de confiance charges de realiser l'interoperabilite des differentes approches. 

Les principes que Ton vient d'enoncer sont a la base de F initiative prise, le 5 avril 2002, par IBM et 
Microsoft, avec le support de Verisign. Les trois editeurs ont ainsi propose conjointement : 

• une roadmap pour la gestion de la securite des services Web ; 

• la specification WS-Security V. 1 .0. 
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Security in a Web Services World 

La proposition de IBM et Microsoft, realisee avec le concours de Verisign, se materialise en deux documents 

publies en avril 2002 : 

IBM/Microsoft/Verisign, Web Services Security (WS-Security), Version 1.0, qui est le document de specification 

d'un systeme de messagerie securisee (disponible a http://www.verisign.com/wss/wss.pdf}. 

IBM/Microsoft, Security in a Web Services World: A Proposed Architecture and Roadmap, Version 1.0, un white 

paper qui presente une vision generale de I'architecture de I'infrastructure de securite pour les services Web, dans 

laquelle la messagerie securisee n'est que la premiere « brique » (voir http://www.verisign.com/wss/architecture- 

Roadmap.pdf). 



Cette proposition a ete accueillie en termes elogieux par la plupart des analystes. La raison principale 
de cet accueil chaleureux doit etre recherchee dans les objectifs ambitieux de la proposition : 

• permettre la reutilisation de la plupart des approches et des technologies de securite existantes et 
deja utilisees par les applications ; 

• atteindre l'interoperabilite des differentes approches de securite. 

Le haut niveau d'abstraction de la specification (assertions, jetons de securite, contrat de securite) 
s'explique par cette volonte de reutilisation et d'interoperabilite, dans un cadre conceptuellement 
unifie, de technologies fort heterogenes. Par exemple, X.509 et Kerberos reposent sur des principes 
completement differents (cle asymetrique contre cle symetrique) : Kerberos est utilise pour la secu- 
rite des domaines Microsoft Windows 2000 et il est clair qu'il est dans l'interet des utilisateurs de ne 
pas changer de technologie de securite lors de la mise en place, dans les merries contextes (de reseaux 
d'entreprise), des architectures de services Web. 

L'infrastructure de securite pour les services Web 

Dans les architectures orientees services, baties sur le socle technologique des services Web, les 
applications reparties interagissent entre elles exclusivement par echange de messages. Lobjectif 
general qui vise a garantir la securite de bout en bout, se decline done pour ces architectures en un 
nombre restreint d'objectifs plus specifiques : 

• la confidentialite du message de bout en bout ; 

• Yintegrite du message de bout en bout ; 

• la garantie de traitement du message par le destinataire seulement lorsque le message contient la 
preuve des revendications exprimees par Fexpediteur et demandees par le destinataire (authentifi- 

cation, autorisation). 

Ces objectifs peuvent etre atteints : 

• par la specification de langages de description, de formats de message et de protocoles normalises 
comme extensions des technologies des services Web basiques ; 

• par la mise en ceuvre d' implementations conformes aux specifications sur des environnements 
techniques heterogenes. 
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Les exigences operationnelles et les technologies heterogenes que nous avons evoquees impliquent 
que 1' architecture de l'infrastructure de securite soit en meme temps « generique », configurable et 
extensible. La solution retenue est un langage qui permet d'exprimer des assertions sous une forme 
generique sujet/predicat, ces assertions pouvant etre utilisees a des fins differentes. 

L'element essentiel du modele est la notion de revendication : la revendication est une assertion sur 
une entite, emise par l'entite elle-meme ou par une autre entite a qui on fait confiance. Les entites en 
question sont des acteurs humains ou organisationnels ou des agents logiciels. 

Une revendication : 

• est exigee par le destinataire d'un message : le destinataire exige une certaine revendication de la 
part de l'expediteur ; en tant que telle, l'exigence fait partie du contrat de securite publie par le 
destinataire ; 

• est exhibee, avec sa preuve, par l'expediteur du message, lorsqu'il s'adresse au destinataire qui 
l'exige dans son contrat : elle est done inseree dans un jeton de securite qui en fournit la preuve sur 
la base d'un mecanisme de confiance. 

Le jeton de securite est un objet qui contient des revendications que l'expediteur du message fournit 
au destinataire. Un jeton de securite peut etre signe par le createur du message. 




Figure 19-6 

Architecture generate de securite. 



Le modele general de 1' architecture comporte trois roles (voir figure 19-6) : 

• le role de producteur/expediteur d'(une partie d')un message ; 

• le role de destinataire/consommateur d'(une partie d')un message ; 

• le role de tiers de confiance (distributeur de jetons de securite). 
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Le destinataire publie un contrat de securite. L'expediteur insere dans le message, eventuellement 
chiffre et signe par lui-meme, le jeton de securite contenant les revendications exigees par le contrat 
du destinataire. Ce jeton peut etre obtenu aupres d'un tiers de confiance qui joue le role de service de 
distributeur de jetons de securite. Le service de distribution de jetons est un service Web, et, comme 
tel, publie un contrat de securite qui lui est propre. Le service de distribution des jetons peut aussi 
devoir s'authentifier aupres de ses interlocuteurs, ce qui peut dormer lieu a une structure arborescente 
de services de distribution de jetons. Les jetons peuvent egalement etre exhibes par le destinataire (si, 
par exemple, l'expediteur exige Fauthentification du destinataire). 

L'architecture des specifications de securite 

La roadmap Security in a Web Services World presente une architecture de specifications de securite 
par niveaux illustree figure 19-7. 
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Figure 19-7 

Architecture des specifications de {'infrastructure de securite pour les services Web. 

Les bases de l'architecture des specifications sont les recommandations W3C XML Signature et 
XML Encryption (voir plus loin les sections respectives) et, bien evidemment, le protocole SOAP (la 
note W3C SOAP 1.1 et la recommandation candidate W3C SOAP 1.2). C'est une architecture des 
specifications construite sur trois strates : 

• la premiere strate comprend une specification de messagerie securisee (WS-Security), qui met en 
ceuvre l'integrite et la confidentialite du message et fournit le mecanisme d'association de jetons 
de securite au message ; 

• la deuxieme strate, intermediate, comprend les specifications WS-Policy (langage de definition 
d' engagements de securite), WS-Trust (un framework pour construire des modeles de confiance) et 
WS-Privacy (un modele pour les assertions sur les preferences en termes de politique de discretion 
et de confidentialite) ; 

• la troisieme strate comprend WS-SecureConversation (specification de protocoles d'authentifica- 
tion reciproque et d'etablissement des contextes de securite entre applications), WS-Federation 
(mecanismes de federation d'espaces de confiance heterogenes, par exemple X.509 et Kerberos) et 
WS-Authorization (specification des protocoles d'autorisation). 
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La premiere strate : WS-Security 

WS-Security est la specification de la messagerie securisee : il s'agit d'une extension standard de SOAP 
par definition d'entrees de Fen-tete. La messagerie securisee permet la mise en ceuvre de Fintegrite et 
de la confidentialite du message et fournit un mecanisme general pour associer des jetons de securite a 
un message SOAP. 

L'integrite des messages est mise en ceuvre par Futilisation conjointe d'XML Signature et des 
jetons de securite (qui peuvent contenir des cles publiques). Le mecanisme permet la signature 
multiple et conjointe de plusieurs acteurs. Le mecanisme est extensible et prend en charge des 
nouveaux formats de signature. 

La confidentialite des messages est assuree par Futilisation conjointe des mecanismes de chiffre- 
ment d'XML Encryption et des jetons de securite. La confidentialite ne peut s'appliquer qu'a des 
parties du message. Les mecanismes de chiffrement sont concus de facon extensible, pour permettre 
la prise en charge d'autres technologies et processus de chiffrement. 

La specification WS-Security ne preconise pas de format de jeton de securite. En revanche, elle 
specifie une methode standard pour creer de nouveaux formats de jetons et un mecanisme de codage 
de jetons binaires. 

La deuxieme strate 

Les specifications de la strate intermediate (WS-Policy, WS-Trust et WS-Privacy) s'appuient direc- 
tement sur WS-Security. 

WS-Policy 

Ce langage permet de specifier le contrat de securite : il specifie comment exprimer les exigences 
de securite du destinataire du message et les capacites de securite de l'expediteur. La specification 
est totalement extensible et ne limite ni les types d'exigences ni les capacites que Fon peut decrire. 
Neanmoins, la specification fixe certains attributs essentiels pour exprimer les exigences de confi- 
dentialite, les formats de codage, les exigences en jetons de securite, les algorithmes pris en 
charge. 

WS-Policy decrit un format generique qui permet d'exprimer directement ou par reference des 
exigences et des capacites dans un message SOAP, au-dela du domaine de la securite. 

WS-Trust 

WS-Trust specifie le modele des mecanismes pour etablir des relations de confiance, soit directes, 
soit indirectes via les services d' intermediation de tiers de confiance (services de distribution de 
jetons de securite). Le service de distribution de jetons de securite se fonde sur l'infrastructure de 
messagerie securisee WS-Security pour transmettre les jetons de securite de facon a assurer leur 
confidentialite et integrite. La specification definit comment plusieurs mecanismes d'etablissement 
de la confiance peuvent etre utilises dans le cadre du modele. 

WS-Privacy 

WS-Privacy est un langage de specification de regies de discretion et de confidentialite. 
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Porteede WS-Policy 

Deja, la roadmap Security in a Web Services M/br/dd'avril 2002, que nous sommes en train de resumer dans cette 
section, envisage pour WS-Policy un role au-dela de la specification d'exigences et de capacites de securite. 
La notion de policy, qu Ton peut traduire par « mesure », « regie » ou encore « principe » est bien adaptee pour 
enoncer des engagements (requis ou proposes) de service au sens large, et notamment les engagements de 
qualite de service. Dans le chapitre 3, nous avons defini la qualite de service comme un ensemble de proprietes 
operationnelles (non fonctionnelles) du service : la performance, la fiabilite, la disponibilite, la continuite et aussi 
la securite. L'expression d'engagements (et de demandes d'engagement) de securite est absolument neces- 
saire pour faire fonctionner une infrastructure efficace : c'est la raison pour laquelle une specification de ce type 
surgit d'une architecture de securite. Cela dit, les auteurs de la roadmap se rendent compte de la portee bien 
plus large d'une telle specification. 

Ces exigences de qualite, integrees dans un document WSDL, constituent des clauses du contrat de service. 
Integrees dans un message SOAP, elles font I'objet d'une negotiation a I'execution ; integrees dans une entite 
UDDI, elles presentent les principes de qualite de service et de securite que I'entite met en oeuvre et exige. La 
roadmap envisage une utilisation de WS-Policy au-dela du perimetre de securite, mais semble la cantonner a 
une extension de SOAP. L'extension eventuelle de WSDL pour la publication de clauses de securite semble 
negligee. 

Les specifications WS-Policy, parues en decembre 2002 (voir la remarque « Avancement de la roadmap Secu- 
rity in a Web Services World ») generalised non seulement la notion de policy au-dela de la securite, mais defi- 
nissent egalement le mecanisme d'inclusion, par valeur et/ou par reference, de policies dans les messages 
SOAP, les documents WSDL et les annuaires UDDI. Les specifications WS-Policy constituent sans doute le 
framework pour la definition ulterieure d'exigences et de contraintes de qualite de service au sens large du 
terme. 



Les organisations prestataires et clientes de services doivent pouvoir exprimer leurs regies de discre- 
tion et de confidentialite et exiger qu'un message exhibe des revendications de conformite a ces 
regies de la part de l'expediteur. Sur la base des outils specifies par WS-Security, WS-Trust et WS- 
Policy, les applications peuvent exprimer leurs engagements quant au respect de ces regies. La speci- 
fication decrit comment les regies de confidentialite et de discretion WS-Privacy : 

• sont emboitees dans des elements WS-Policy ; 

• peuvent faire I'objet de revendications associees a des messages WS-Security ; 

• interviennent dans les protocoles d'etablissement de relations de confiance WS-Trust. 

La troisieme strate 

La troisieme strate permet la mise en ceuvre de l'interoperabilite entre approches de securite hetero- 
genes (WS-SecureConversation, WS -Federation) et donne un cadre general de traitement des meca- 
nismes d'autorisation pour les architectures de services Web (WS-Authorization). 

WS-SecureConversation 

La specification WS-SecureConversation decrit comment le client et le prestataire d'un service Web 
peuvent s'authentifier mutuellement et etablir dynamiquement des contextes de securite authentifies. 
La specification decrit notamment les protocoles destines a etablir a la volee des cles symetriques 
pour une seule interaction ou pour une session. 
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La specification s'attaque egalement aux mecanismes d'echange de contextes de securite (un ensemble 
de revendications de securite avec les donnees associees) via l'utilisation de : 

• Fechange de jetons de securite par WS-Security ; 

• la creation et la distribution des jetons de securite par WS-Trust ; 

WS-SecureConversation utilise WS-Security : les messages des conversations securisees peuvent 
traverser plusieurs intermediaries qui utilisent des protocoles de transport differents. WS-Secure- 
Conversation et WS-Security sont concues pour permettre l'utilisation independante de mecanismes 
de securite au niveau transport, par exemple entre certains des nceuds de la chaine d'acheminement, 
afin d'accroitre la securite globale des architectures de services Web. 

WS-Federation 

WS-Federation specifie, sur la base de WS-Security, WS-Policy, WS-Trust et WS-SecureConversation, 
comment il est possible de construire des espaces de confiance globaux, qui comprennent des appro- 
ches de securite heterogenes : par exemple, comment etablir un contexte de securite commun entre 
applications qui utilisent Kerberos et X.509 comme mecanismes d' authentication. La specification 
introduit un langage de description de regies de confiance (reposant sur WS-Policy) qui permet de 
batir des mecanismes de gestion des relations de confiance dans des environnements heterogenes et 
qui permet done concretement d'effectuer Fauthentification reciproque entre applications qui utilisent 
des approches de securite heterogenes. 

WS-Authorization 

La specification WS-Autorisation s'attaque a la standardisation d'un domaine (celui de Fautorisa- 
tion) hautement complexe et qui est aujourd'hui traite au niveau applicatif avec des solutions ad hoc. 
Dans le contexte de la technologie des services Web, l'autorisation concerne specifiquement les 
droits et habilitations d'une application cliente a Faeces aux prestations d'un service Web. 

WS-Authorization decrit done comment : 

• specifier et gerer des regies d'autorisation (toujours dans le cadre de WS-Policy) ; 

• certifier les revendications d'autorisation (avec des jetons de securite WS-Trust) ; 

• echanger ces revendications d'autorisation via WS-Security ; 

• interpreter correctement ces revendications pour controler Faeces aux prestations de services. 
La specification permet des adaptations et des extensions du format et du langage des autorisations. 

Le developpement de l'infrastructure de securite des services Web 

En juin 2002, IBM, Microsoft et Verisign manifestent la volonte de soumettre la specification WS- 
Security a FOASIS pour que cette organisation prenne en main le processus de standardisation de la 
specification. 

Baltimore Technologies, BEA Systems, Blockade Systems, Cisco Systems, Commerce One, Docu- 
mentum, Entrust, Fujitsu, Intel Corporation, IONA, Netegrity, Novell, Oblix, OpenNetwork, Perfi- 
cient, RSA Security, SAP AG, SeeBeyond, Sonic Software, Sun Microsystems, Systinet, TIBCO, 
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VeriSign, Vodafone, WebMethods, XML Global se declarent disponibles et prets a participer a 
1' effort de specification et de normalisation dans le cadre d'un comite technique OASIS. 

L' adhesion de Sun Microsystems a la demarche est particulierement importante. En fait, Sun est le 
principal promoteur et membre fondateur, avec American Express, America Online, France Telecom, 
General Motors, Hewlett Packard, Master Card, Nokia, NTT DoCoMo, RSA Security, Sony et 
Vodaphone, du projet Liberty Alliance (voir http://www.projectliberty.org), lequel vise a produire des 
specifications pour une infrastructure ouverte d' identification single sign-on (SSO) des internautes. 
Ce projet a encore comme objectif de contrer le projet MyService .NET de Microsoft, considere 
comme proprietaire ou trop marque par le leadership de l'editeur de Redmond (voir le chapitre 15). 
La soumission du travail effectue par Liberty Alliance a OASIS est envisagee. 

Par ailleurs, IBM, Microsoft et Verisign annoncent qu'ils continuent a developper les specifications 
annoncees dans la roadmap Security in a Web Services World d'avril 2002. 



Avancement de la roadmap Security in a Web Services World 

IBM et Microsoft publient, avec Verisign, le 18 aout 2002 un addendum a WS-Security : 

- IBM, Microsoft, Verisign, Web Services Security Addendum, Version 1.0 (voir http://www.verisign.com/wss/WS- 
Security-Addendum.pdf) . 

lis publient le 18 decembre 2002, avec le concours de BEA et SAP, un ensemble consequent de documents : 

- IBM, Microsoft, BEA, SAP, Web Services Policy Framework (WS-Policy), Version 1.0. Ce document specifie le 
modele general et la syntaxe permettant de decrire et de communiquer via SOAP les policies d'un service Web 
(voi r http://www. verisign. com/wss/WS-Policypdf) . 

- IBM, Microsoft, BEA, SAP, Web Services Policy Attachment (WS-PolicyAttachment), Version 1.0. Ce document 
definit le mecanisme qui permet d'associer des policies avec des elements WSDL (types et portType) et des entites 
U D D I (voi r http://www. verisign. com/wss/WS-PolicyAttachment.pdf) . 

- IBM, Microsoft, BEA, SAP, Web Services Policy Assertion Language (WS-PolicyAssertion), Version 1.0. Ce docu- 
ment definit un langage d'assertions de policies avec un certain nombre de types d'assertions predefinis sur le 
langage, le mecanisme d'encodage du texte, la version de specification prise en charge... (voir http://www.veri- 
sign. com/wss/WS-PolicyAssertions.pdf) . 

Dans cet ensemble, I'autonomie de la specification WS-Policy par rapport a la problematique de la securite est offi- 
ciellement reconnue : WS-Policy devient un premier ensemble de specifications « correlees » qui ont une fonction 
« utilitaire » par rapport au corpus de securite mais dont la portee depasse la gestion de la securite. A la meme 
date, IBM, Microsoft et Verisign, rejoints par RSA Security, publient un ensemble de specifications de I'infrastruc- 
ture de securite en coherence avec la roadmap : 

- IBM, Microsoft, RSA Security, Verisign, Web Services Security Policy Language (WS-SecurityPolicy), 
Version 1.0. II s'agit du module qui, dans I'architecture originelle des specifications de I'infrastructure de securite, 
s'appelait WS-Policy. En fait, il s'agit des assertions de policies qui s'appliquent a WS-Security (voir http://www.veri- 
sign.com/wss/WS-SecurityPolicy.pdf). 

- IBM, Microsoft, RSA Security, Verisign, Web Services Trust Language (WS-Trust), Version 1.0. Ce document 
presente la specification des formats pour demander et emettre des jetons de securite et pour gerer des relations 
de confiance (voir http://www.verisign.com/wss/WS-Trust.pdfj. 

- IBM, Microsoft, RSA Security, Verisign, Web Services Secure Conversation Language (WS-SecureConversation), 
Version 1.0. Ce document est une specification sur la base de WS-Security des formats et protocoles pour mettre en 
ceuvre la communication securisee, le partage de contextes de securite avec prise en charge de cles symetriques de 
session (voir http://www.verisign.com/wss/WS-SecureConversation.pdf). 
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OASIS/Web Services Security Technical Committee (OASIS/WSSTC) 

L'objectif explicite du Web Services Security (WSS) TC {http://www.oasis-open.org/committees/ 
tc_home.php?wg_abbrev=wss) est de finaliser le travail relatif a l'infrastructure de base de securite des services 
Web (WS-Security), telle qu'elle est decrite dans la roadmap Security in a Web Services World et dont la premiere 
version est consignee dans WS-Security 1 .0. Le travail du WSS TC est de batir les fondations techniques pour des 
services de securite de plus haut niveau (tels qu'ils sont decrits dans la roadmap) a definir dans d'autres specifica- 
tions. II n'est pas dans la mission du WSS TC de developper la roadmap, qui n'est pas un document normatif du 
TC. 

Les resultats (intermediaires, a I'etat de draft) des travaux du WSS TC sont presented dans un document de speci- 
fication WSS-Core, dans I'axe de la normalisation de WS-Security, et des documents dits de « profil » : 
OASIS, Web Services Security, SOAP Message Security, Working Draft 1 1 (3 mars 2003) : cette specification 
propose un ensemble d'extensions SOAP destinees a mettre en ceuvre I'integrite et la confidentialite au niveau 
message (echange) et a associer au message des jetons de securite. L'ensemble de ces extensions est aussi 
appele WSS-Core, pour Web Services Security Core Language (voir http://www.oasis-open.org/committees/down- 
load.php/1043/WSS-SOAPMessageSecuhty-1 1-0303.pdf). La specification s'appuie sur SOAP 1.2 (en etat de 
candidate recommandation). 

A cette specification, le WSS TC associe un ensemble de documents definissant des « profils » de jetons de secu- 
rite qui indiquent comment construire des jetons de securite suivant des approches specifiques : 

- OASIS, Web Services Security Username Token Profile, Working Draft 2 (23 fevrier 2003) : cette specification 
decrit la creation et I'utilisation de jetons de securite WSS-Core qui identifient un acteur par son nom d'utilisateur et 
I'authentifient par un mot de passe, ou un autre secret partage (voir http://www.oasis-open.org/committees/wss/ 
documents/WSS-Username-02-0223.pdf). 

- OASIS, Web Services Security Kerberos Token Profile, Working Draft 03 (30 Janvier 2003) : cette specification 
decrit I'utilisation des tickets et authentifiers Kerberos dans des jetons de securite WSS-Core (voir http:// 
www.oasis-open.org/committees/wss/documents/WSS-Kerberos-03.pdf). Pour la technologie Kerberos, voir la 
remarque « Kerberos » dans la section introductive du present chapitre. 

- OASIS, Web Services Security SAML Token Profile, Working Draft 06 (21 fevrier 2003) : cette specification decrit 
comment integrer les assertions SAML (Security Assertion Markp Language) dans les jetons de securite WSS- 
Core (voir http://www.oasis-open.org/committees/wss/documents/WSS-SAML-06-changes.pdf). La technologie 
SAML (Security Assertion Markup Language) est specifier par le comite technique OASIS Security Services (http:/ 
/www.oasis-open.org/committees/tc_home.php?wg_abbrev=security) : il s'agit d'un framework XML dedie a 
I'echange d'informations d'authentification et d'autorisation, dont la version 1.0 est un standard OASIS depuis le 
5 novembre2002 (http://www.oasis-open.org/committees/download.php/1383/oasis-sstc-saml-1.0-pdf.zip). 

- OASIS, Web Services Security X509 Certificate Token Profile, Working Draft 03 (30 Janvier 2003) : cette specifi- 
cation decrit comment integrer des certificats X.509 dans les jetons de securite WSS-Core (voir http://www.oasis- 
open.org/committees/wss/documents/WSS-X509-03.pdf). Pour la technologie X.509, voir la remarque « X.509 » 
dans la section introductive du present chapitre. 

- OASIS, Web Services Security XrML-Based Rights Expression Token Profile, Working Draft 03 (30 Janvier 2003) : 
cette specification decrit comment integrer les licenses, a savoir des revendications de propriete intellectuelle, en 
REL (Right Expression Language), lequel repose sur XrML (extensible rights Markup Language), dans les jetons 
de securite WSS-Core (voir http://www.oasis-open.org/committees/wss/documents/WSS-XrML-03.pdf). La techno- 
logie XrML (extensible rights Markup Language, http://www.xrml.org) est une proposition de la societe Content- 
Guard Inc. qui a ete soumise au groupe de travail MPEG {http://mpeg.telecomitalialab.com/index.htm) de NSO/IEC 
(International Organization for Standardization/International Electrotechnical Commission). XrML est utilise dans 
ce contexte en tant que base pour MPEG-21 REL (Rigths Expression Language), qui, selon le plan affiche, est 
destine a devenir un standard international courant 2003. 
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- OASIS, Web Services Security XCBF Token Profile, Working Draft 1.0 (25 novembre 2002) : cette specification decrit 
comment integrer des donnees biometriques au format XCBF (XML Commont Biometric Format) dans des jetons de 
securite WSS-Core (voir http://www.oasis-open.org/committees/wss/documents/WSS-XCBF.pdf). La technologie 
XCBF (XML Common Biometric Format) est en cours de specification par le XCBF TC d'OASIS (http://www.oasis- 
open.org/committees/tc_home.php?wg_abbrev=xcbf). En fait, il s'agit de la traduction en XML de CBEFF (Common 
Biometric Exchange File Format), un standard du NIST (National Institute of Standards and Technology) americain 
(http://www.itl.nist.gov/div895/isis/bc/cbeffj. 



WSS-Core 



La specification WSS-Core fournit le mecanisme qui permet de proteger un message par chiffrement et/ 
ou signature d'elements du corps, de Fen-tete, de pieces jointes ou de toute combinaison de ces objets. 

L'integrite du message est obtenue par l'utilisation d'XML Signature avec les jetons de securite pour 
assurer que les messages sont recus sans modification. Les mecanismes d'integrite sont concus pour 
prendre en charge plusieurs signatures, effectuees potentiellement par des intermediaries dans une 
chaine d'acheminement. Les mecanismes sont extensibles dans le sens ou ils s'accommodent de 
plusieurs formats de signature. 

La confidentialite d'un message est obtenue par l'utilisation conjointe d'XML Encryption en conjonc- 
tion avec des jetons de securite. Les mecanismes de chiffrement sont concus de facon a assurer des 
processus de chiffrement conduits independamment de la part de plusieurs nceuds/roles SOAP. 

La specification definit la syntaxe et la semantique des signatures dans les elements wsse : Securi ty et, 
a l'inverse, ne comprend aucun mecanisme de signature qui apparait a l'exterieur des elements 

wsse:Security. 

Le destinataire du message devrait rejeter un message : 

• avec une signature invalide ; 

• avec des revendications invalides ; 

• avec des revendications manquantes. 

La specification definit le mecanisme utilise par l'expediteur du message pour exprimer des revendi- 
cations relatives a la securite par l'association d'un ou plusieurs jetons de securite au message. Un 
exemple typique de revendication de securite est la revendication d'identite de l'expediteur. 

Plusieurs profils (formats) de jetons de securite sont definis par des specifications complementaires (voir 
la remarque « OASIS/WEb Services Security Technical Committee (OASIS/WSS TC) » ci-dessus). 

Vocabulaires XML et prefixes 

Prefixe Vocabulaire XML 

wsse http://schemas.xmlsoap.org/ws/2002/xx/secext 

S http: //www. w3.org/ 2002/ 12/ soap- envelope 

ds http://www.w3.Org/2000/09/xmldsig# 

xenc http://www.w3.org/2001/04/xml enc# 

wsu http: //schemas. xmlsoap.org/ws/2002/xx/util ity 

xsd http://www.w3.org/2001/XMLSchema 
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XML Signature 

XML-Signature Syntax and Processing (en abrege XML Signature), recommandation du W3C du 
12 fevrier 2002 (http://www.w3.org/TR/xmldsig-core), est une specification du mecanisme qui permet de 
creer et de representer en XML des signatures numeriques qui s'appliquent a des objets heterogenes, 
y compris des fragments XML. 

Le pivot de la specification est l'element Signature, dont voici le gabarit : 

<Signature [Id="xsd:ID"]> 
<SignedInfo> 
<Canonical izationMethod Al gorithm="xsd:anyt//?J"/> 
<SignatureMethod Algorithm="xsa l :any(//?I'7> 
^Reference [URI = " xsd:anyURI"]> 
[<Transforms> 

(<Transform Algorithm^" xsd : anyURI" />)+ 
</Transforms>] 

<DigestMethod Al gorithm=" xsd : anyURI" /> 
<DigestVal ue>xsd:£>3se64fi7'nary</DigestValue> 
</Reference>)+ 
</SignedInfo> 

<SignatureValue>xsfl':ii3se64B7A)ary</SignatureVal ue> 
[<KeyInfo>...</KeyInfo>] 
(<0bject>...</0bject>)* 
</Signature> 

L'element Si gnature inclut deux sous-elements : 

• Si gnedlnf o, qui vehicule des informations sur la signature et l'objet signe ; 

• Si gnatureVal ue, qui contient la chaine d'octets resultat de la procedure de signature. 
II contient egalement d'autres elements optionnels : 

• Key Info, qui permet au destinataire d'obtenir la cle de validation de la signature ; 

• Object, qui contient des informations accessories, comme des timestamps, et eventuellement 
l'objet a signer (signature enveloppante). 

La procedure de signature 

Pour chaque objet a signer, la procedure est la suivante : 

1. Application des eventuels algorithmes de transformation (qui seront indiques dans Transforms) a 
l'objet (optionnel). 

2. Calcul du condense de l'objet (digest) par un algorithme de hachage (qui sera indique dans 

DigestMethod). 

3. Creation de Felement Reference, incluant l'attribut d' identification URI (optionnel), les eventuels 
elements, dans Transforms, qui designent les algorithmes de transformation, l'element Digest- 
Method qui indique 1' algorithme de hachage et Felement DigestValue dont la valeur, codee en 
base 64, est le condense. 

4. Creation de l'element Signedlnfo avec les descendants SignatureMethod, Canonical ization- 
Method et Ref erence(s). 
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5. Application de Falgorithme de canonisation indique dans Canonical izationMethod sur 
Signedlnfo. 

6. Application de Falgorithme de signature indique dans SignatureMethod sur le format canonique 
de Signedlnfo. Le resultat, code en base 64, est le contenu del'element SignatureValue. 

7. Construction de Felement Signature, qui comprend Signedlnfo, SignatureValue, Keylnfo (si 
necessaire) et Object(s) (si necessaire). 



Format canonique XML 

Deux documents XML egaux du point de vue applicatif peuvent etre « physiquement » differents et done donner 
des resultats differents s'ils sont soumis a des procedures de signature ou de chiffrement. Dans le cadre de I'acti- 
vite XML Signature, un groupe de travail conjoint IETF/W3C (http://www.w3.org/Signature/Overview.htmt} a speci- 
fic un format « canonique » d'un document XML : I'application de la procedure de canonisation a deux documents 
egaux du point de vue applicatif mais physiquement differents donne le meme format canonique. 
Le groupe de travail a produit deux specifications : 

- Canonical XML, Version 1.0, recommandation du 15 mars 2001, accessible a http://www.w3.org/TR/xml-c14n, 
qui fait egalement I'objet de la IETF-RFC3076 {http://www.iett.org/rfc/rfc3076.txf) ; 

- Exclusive XML Canonicalization, Version 1.0, recommandation du 18 juillet 2002, accessible a http:// 
www.w3.org/TR/xml-exc-c14n. Le format canonique exclusif permet de calculer un format canonique d'un fragment 
XML independamment du contexte du document englobant. Cet algorithme est preconise pour les signatures dans 
WSS-Core. 



La procedure de validation 

1. Calcul du format canonique de Signedlnfo, sur la base de 1' algorithme indique dans Canonicali- 
zationMethod. 

2. Pourchaque Reference dans Signedlnfo : 

- recuperation de I'objet pour lequel il faut calculer le condense ; 

- application de la fonction de hachage Reference/DigestMethod ; 

- comparaison de la valeur calculee, codee en base 64, avec la valeur presente dans Refe- 
rence/DigestVal ue ; si les valeurs sont differentes, alors la validation echoue. 

3. Obtention des informations sur la cle de validation d'une source exterieure ou de Keylnfo. 

4. Application de Falgorithme de validation Signedlnfo/SignatureMethod a SignatureValue par 
rapport a Signedlnfo ; si Falgorithme echoue, la validation est en echec. 

XML Encryption 

XML Encryption Syntax and Processing (en abrege XML Encryption), recommandation du W3C du 
10 decembre 2002 (http://www.w3.org/TR/xmlenc-core), est une specification d'un mecanisme de chiffre- 
ment d'objets et de representation du resultat chiffre en XML. Les donnees chiffrables sont des objets 
heterogenes (types MIME), des elements XML ou des contenus (sous-elements et/ou donnees carac- 
teres) d' elements XML. Le resultat de la procedure de chiffrage est un element XML qui contient ou 
qui reference les donnees chiffrees, en plus des informations sur le chiffrement. 
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Voici le gabarit des donnees chiffrees et des informations de chiffrage : 

<EncryptedData [Id="xsd: ID"] [Type="xsd:anyl//?I"] [MimeType="xsd: string"'] 
[Encodings" xsd : a/jyl//?I"]> 
[< Encrypt ionMet hod Algorithm="xsc/:anyl//?I" >...</ Encrypt ionMethod>] 
[<ds:KeyInfo> 
[<EncryptedKey [Id="xsrf: ID" ]>...</EncryptedKey>] 
[<AgreementMethod Algorithm="xsa':any[//?J" >...</ AgreementMethod>] 
[<ds : KeyName>xsd:str7'ng</ds : KeyName>] 
[<ds: Retrieval Method {UR1 = " xsd :anyllRI"1 
[Type="xsd:any(//?r]>...</ds:RetrievalMethod>] 

</ds:KeyInfo>] 
<CipherData> 
(<Ci pherVal ue>xsd:base64B1nary</C : \ pherVal ue> | 
<CipherReference URI = "xsd:anyt//?I">...</CipherReference>) 
</CipherData> 

[<Encrypti on Properties)..// Encrypti on Properties>] 
</EncryptedData> 

XML Encryption utilise des formats et des regies de traitement specifies dans XML Signature, 
comme ds : Key Info (les noms des elements XML Signature sont qualifies par les prefixes ds dans le 
gabarit). Les donnees chiffrees sont soit incluses par valeur (Ci pherVal ue), soit referencees (Cipher- 
Reference) dans EncryptedData. Des informations complementaires sont hebergees dans Encryption- 
Properties. Pour chiffrer des cles, XML Encryption utilise l'element EncryptedKey, qui presente le 
meme gabarit qu' EncryptedData. 

La procedure de chiffrement 

1. Selection de l'algorithme de chiffrement et de ses parametres (a indiquer par la suite dans 

EncryptionMethod). 

2. Identification et representation de la cle de chiffrement : 

- construction de l'element ds:KeyInfo adequat a l'identification de la cle (par nom, par 
reference, etc.) ; 

- si la cle doit etre chiffree, construction de l'element EncryptedKey (l'element EncryptedKey 
est construit par 1' application recursive de cette procedure). 

3. Chiffrement des donnees : 

- si c'est un element ou un contenu XML, le codage UTF-8 s'impose ; 

- si c'est un objet d'un autre type (y compris une cle), la serialisation en une chaine d'octets 
s'impose ; 

- chiffrage par l'utilisation de l'algorithme designe par EncryptionMethod ; 

- annotation du type de donnee chiffree (element, contenu, autre en type MIME, dans les 
attributs EncryptedData/@Type et EncryptedData/@MimeType); 
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4. Construction de la structure EncryptedData ou EncryptedKey (reserve aux cles) : 

- si la donnee chiffree est a inserer dans CipherData, elle doit etre codee en base 64 comme 
contenu de Cipher-Value ; 

- sinon, (la donnee chiffree est memorisee ailleurs), construction de l'element CipherRefe- 
rence avec l'URI de la donnee chiffree. 

5. Placement de l'element EncryptedData ou EncryptedKey : 

- si la donnee chiffree est de type element ou contenu, elle va remplacer l'element ou 
contenu en clair dans le document XML ; 

- sinon, l'application place l'element a sa discretion. 
La procedure de dechiffrement 

Pour chaque element EncryptedData ou EncryptedKey, la procedure est la suivante : 

1. Analyse et traitement de l'element pour determiner l'algorithme de chiffrement, ses parametres 
et les informations ds : Key Info. Si des informations sont omises, l'application doit en disposer par 
ailleurs, sinon la procedure echoue. 

2. Localisation de la cle de chiffrement a l'aide de ds : Key Info et de ses sous-elements. Si la cle est 
chiffree, application recursive de la procedure a l'element EncryptedKey correspondant pour 
extraire la cle. 

3. Dechiffrement des donnees chiffrees CipherData : 

- si les donnees chiffrees sont accessibles par valeur, le contenu de l'element CipherValue 
est decode base 64 ; 

- si les donnees chiffrees sont accessibles par reference, elles sont localisees grace a l'utili- 
sation des informations contenues dans CipherReference et elles sont recuperees ; 

- les donnees chiffrees sont dechiffrees avec l'application de l'algorithme, des parametres 
et de la cle obtenus (pas 1 et 2). 

4. Si les donnees sont de type element ou contenu : 

- la chaine en clair (pas 3) est interpretee comme contenant des donnees caracteres codees 
UTF-8 ; 

- elle remplace l'element EncriptedData avec l'element ou le contenu represente par les 
caracteres codes UTF-8 ; si le document XML recepteur n'est pas code UTF-8, le trans- 
codage de la chaine en clair s' impose. 

5. Si les donnees sont d'un type different d'element ou de contenu : 

- la chaine en clair est traitee selon les indications presentes dans EncryptedData/@Type, 
EncryptedData/@MimeType et EncryptedData/@Encoding ; 

- ce pas s'applique systematiquement a EncryptedKey. 
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L'entree de l'en-tete Security 

La gestion de la securite utilise le mecanisme standard d'extension du message SOAP : les entrees de 
l'en-tete. La gestion de la securite propose l'utilisation de l'entree de l'en-tete wsse: Security. 

Voici le gabarit d'une entree de l'en-tete wsse:Security : 

<S: Envelope> 
<S:Header> 

<wsse: Security [S:role="xs:aAjyt//?J"] [S:mustUnderstand="xs:£>oo7e3n"]> 

</wsse:Security> 

</S:Header> 

<S:Body/> 
</S: Envelope> 

Les elements et attributs du gabarit ont l'usage suivant : 

• l'element /wsse: Security est l'entree de l'en-tete qui permet de transmettre des informations de 
securite a un recepteur designe ; 

• l'attribut /wsse : Security /@S: role designe le consommateur de l'entree de l'en-tete ; cet attribut 
est optionnel mais, dans un message, une seule entree wsse : Securi ty peut ne pas specifier de role ; 

• l'attribut /wsse: Securi ty/@S:mustUnderstand rend la consommation de l'entree de l'en-tete obliga- 
toire ou facultative (par defaut) ; l'usage de cet attribut n'est pas clairement etabli dans le draft, par 
rapport aux contraintes d'usage des elements wsse: Security qui sont repertoriees ci-apres. 

L'element wsse: Security est totalement extensible (en termes d'elements et d'attributs descendants), 
ce qui permet d'integrer par extension pratiquement toutes les approches de securite existantes ainsi 
que de nouvelles approches. 

II peut y avoir plusieurs elements wsse: Security dans l'en-tete du message SOAP. L intermediate 
d'une chaine d'acheminement peut ajouter un ou plusieurs sous-elements dans une en-tete qui lui est 
adressee ou un ou plusieurs elements wsse: Security a destinations d'autres cibles. 

Chaque element wsse : Securi ty d'un message SOAP est adresse a un et un seul nceud SOAP (destina- 
taire ou intermediaire) et chaque nceud peut etre la cible d'un seul element wsse:Security. Toutes les 
informations de securite pour un nceud specifique doivent done etre concentrees dans une seule 
entree wsse: Security. Par ailleurs, une entree wsse: Security peut etre lue par tout nceud de la chaine 
d'acheminement, mais ne peut etre supprimee que par le nceud destinataire. 

La specification WSS-Core preconise une strategie dediee a la construction d'un element wsse : Securi ty 
et a l'ajout a la volee de sous -elements. Le principe est que les sous-elements d'un element wsse:Secu- 
rity devraient etre ordonnes dans une sequence sans references en avant : la progression lineaire de 
l'analyse du contenu de wsse: Security de la part du destinataire coincide avec la sequence des traite- 
ments de dechiffrement et de validation de signature qu'il doit effectuer. Ainsi, par exemple, l'element 
qui vehicule une cle qui doit etre utilisee pour validation de signature devrait preceder l'element de 
description de la signature qui utilise la cle ou, pour une partie signee et ensuite chiffree, l'element 
decrivant le chiffrement doit preceder l'element decrivant la signature. 
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Les jetons de securite 

L' element wsse: Security permet de vehiculer dans Fen-tete du message SOAP des informations de 
securite. 

L'usage d'XML Signature et d'XML Encryption est obligatoire avec les jetons de securite. Cela ne 
veut pas dire que les jetons de securite doivent etre necessairement signes et/ou chiffres, mais seule- 
ment que, s'ils le sont, ils doivent l'etre en conformite avec les normes XML Signature et XML 
Encryption et les regies d'usage etablies par la specification WSS-Core. 

La specification WSS-Core n'indique pas si et comment la preuve d'une revendication doit etre four- 
nie. En revanche, elle etablit comment associer la signature au jeton de securite comme validation de 
la revendication. 

L'element UsernameToken 

L'element wsse: UsernameToken est utilise pour vehiculer un nom d'utilisateur. L'element peut etre 
introduit dans une entree de l'en-tete wsse: Security. 

En voici le gabarit : 

<wsse:llsernameToken [wsu: Id="xsc/:ID"] .„> 
<wsse:Username [wsu: Id="xsd: ID"] ...>wsse:Attr1butedString</visse:[}serr\ame> 

</wsse:UsernameToken> 
Les usages des differents elements et attributs sont decrits ainsi : 

• l'element /wsse : UsernameToken est le jeton de securite utilise pour la revendication d'identite sur la 
base nom d'utilisateur/secret partage ; 

• l'attribut /wsse:UsernameToken/@wsu:Id est utilise comme libelle du jeton de securite ; 

• l'element /wsse:UsernameToken/Username vehicule le nom de l'utilisateur ; 

• l'attribut /wsse:UsernameToken/Username/@wsu: Id est utilise comme libelle du nom d'utilisateur. 

L'element wsse: UsernameToken est totalement extensible (en termes d'elements et d'attributs descen- 
dants), ce qui permet d'integrer par extension toutes les approches d'identification/authentification de 
type nom d'utilisateur/secret partage existantes ainsi que des nouvelles approches. 

Les jetons de securite binaires 

La specification WSS-Core precise comment integrer dans le message les jetons de securite binaires 
(par exemple, les certificats X.509 et les tickets Kerberos) via l'element wsse:BinarySecurityToken. 

En voici le gabarit : 

<wsse:BinarySecurityToken [wsu: Id="xsc/:ID"] 
EncodingType="xsd:QJVame" 
Val ueType="xsd:QiVa/ne" ...>wsse:Encoc/edStr7'ng</wsse:BinarySecurityToken> 

Voici l'usage des differents attributs et elements : 

• l'element /wsse:BinarySecurityToken est le conteneurdu jeton binaire ; 

• l'attribut /wsse:BinarySecurityToken/@wsu: Id est le libelle du jeton (optionnel) ; 
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• l'attribut /wsse:BinarySecurityToken/@ValueType est le libelle du type de donnees binaire encodes 
(par exemple wsse : X509v3, pour les certificats X.509 V3) ; 

• l'attribut /wsse :BinarySecurityToken/@Encodi no. Type est le format de codage des donnees binaires 
emboitees dans le jeton (par exemple, wsse :base64Bi nary). 

L'element wsse:BinarySecurityToken est extensible par rapport aux attributs. 

Les references auxjetons de sec u rite 

L'element wsse:SecurityTokenReference permet d'effectuer, en couplage avec l'attribut wsu:Id de 
l'element cible, l'inclusion par reference d'un jeton de securite. Utilise, par exemple, comme descen- 
dant direct de ds : Key Info (XML Signature, XML Encryption), il permet d'atteindre le jeton de securite, 
utilise pour la signature ou le chiffrement, qui est place ailleurs. 

|<wsse : Securi tyTokenRef erence [wsu : Id="xscf: ID" ]...> 
<wsse: Reference URI=" xsd; a nyURI" [Val ueType="xsd:QA/affle"] .../> 
</wsse: Securi tyTokenRef erence> 

Voici 1' usage des differents attributs et elements : 

• l'element /wsse:SecurityTokenReference fournit la reference au jeton de securite ; 

• l'attribut /wsse: Securi tyTokenRef erence/@wsu: Id est le libelle de la reference ; 

L'element wsse:SecurityTokenReference est totalement extensible (en termes d' attributs et d' elements 
descendants). 

La specification definit trois types de reference : 

• la reference directe ; 

• l'identifiantde cle ; 

• les autre types de references (pour traiter des cas particuliers). 

Les references directes 

Les references directes sont realisees par l'element wsse: Reference : 

|<wsse : Securi tyTokenRef erence [wsu : Id="xsc/: ID" ]...> 
<wsse:Reference URI = " xsd :anyURI" [Val ueType="xsd:QA/ame"] .../> 
</wsse: Securi tyTokenRef erence> 

Voici l'usage des differents attributs et elements : 

• l'element /wsse: Securi tyTokenRef erence/wsse: Reference est utilise pour porter un URI qui 
permet de localiser le jeton de securite ; 

• l'attribut /wsse: Securi tyTokenRef erence/wsse : Reference/@URI est l'URI du jeton ; 

• l'attribut /wsse: Securi tyTokenRef erence/wsse : Reference/@Val ueType indique le type du jeton 
binaire (optionnel). 

L'element wsse : Reference est extensible par rapport aux attributs. 
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Les identif iants de cle 

En alternative de la reference directe, il est possible d'utiliser un identifiant binaire de cle. 
En voici le gabarit : 

<wsse: Security To ken Reference ...> 

<wsse: Key Identifier [wsu: Id="xsd: ID"] 
Val ueType="xsc/:0/Va/ne" 
EncodingType="xsd:QAfame"...>wsse:£ncoded5tr7'ng</wsse: Key Identified 

</wsse:SecurityTokenReference> 
Voici maintenant F usage des differents attributs et elements : 

• Felement /SecurityTokenReference/Keyldentifier est le con teneur del' identifiant binaire de la cle ; 

• Fattribut /Securi tyTokenReference/KeyIdentifier/@wsu: Id est le libelle (optionnel) ; 

• l'attribut /Securi tyTokenReference/ Key Identifier/OValueType indique le type de jeton identifie ; 

• l'attribut /Securi tyTokenReference/KeyIdentifier/@EncodingType indique le format de codage de 
F identifiant binaire (parexemple wsse:Base64Binary). 

L' element wsse : Key Identi f i er est extensible par rapport aux attributs. 

La signature 

La specification WSS-Core impose l'usage d'XML Signature avec certaines limitations. L'objectif, 
pour la securite de bout en bout, est de permettre que plusieurs signatures avec differents formats 
puissent etre integrees au message. 

Les signatures XML Signature (elements ds: Signature) sont emboitees dans des entrees d'en-tete 
wsse : Securi ty. Lobjet signe peut etre un element a Finterieur de l'enveloppe SOAP ou une piece jointe. 

La specification preconise 1' utilisation de l'algorithme de calcul du format canonique Exclusive 
XML Canonicalization (qui est robuste par rapport a 1' utilisation des espaces de noms et des noms 
qualifies dans les fragments XML) et, pour les elements qui sont signes avant chiffrement, de Decrip- 
tion Transformation for XML Signature. 

La signature des jetons de securite 

II est parfois souhaitable, voire necessaire, de signer des jetons de securite. XML Signature permet de 
referencer l'objet signe par une panoplie de moyens (URI, ID, expressions XPath), mais certains 
formats de jetons demandent d'autres techniques de referencement, qui sont prises en charge par 
wsse: Securi tyTokenReference et qui permettent de referencer des jetons de tout format. 

Pour pallier ce probleme, la specification WSS-Core definit une nouvelle technique de reference pour 
XML Signature: l'algorithme STR Dereference Transform (identifie par l'URI http://sche- 
mas. xmlsoap.org/2002/xx/STR-Transform). Lorsque dans un element ds:Signature, l'objet cible (desi- 
gnee par l'URI calcule a partir de son libelle wsu: Id, par exemple) est un wsse:SecurityTokenReference 
et 1'algorithme de resolution de reference est bien http://schemas.xmlsoap.org/2002/xx/STR-Trans- 
form, alors le resultat de la resolution de reference est le jeton reference par wsse: Securi tyTokenRefe- 
rence et non Felement lui-meme. 
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La validation de la signature 

La validation de la signature de la part du destinataire echoue si : 

• la syntaxe de wsse: Security et ds: Signature n'estpas conforme ; 

• la validation de la signature en conformite avec la specification XML Signature echoue ; 

• 1' accreditation de l'expediteur n'est pas acceptable par le destinataire (defaut de confiance). 

Le chiffrement 

La specification WSS-Core permet le chiffrement de toute combinaison d'elements de l'enveloppe et 
de pieces jointes, par cle symetrique et asymetrique, sur la base d'XML Encryption. La procedure de 
chiffrement comprend le chiffrement proprement dit et la generation d'elements dans une entree 
de l'en-tete wsse : Securi ty. 

Les elements suivants, definis par XML Encryption, sont utilises : 

• l'element xenc : Ref erenceLi st peut etre utilise pour une liste generale d'elements chiffres ; 

• les elements chiffres (ou leurs contenus) sont emboites dans des elements xenc: EncryptedData ; 

• les elements chiffres sont references au moyen d'elements xenc: Data Reference contenus dans 

xenc:ReferenceList ; 

• les cles utilisees sont specifiers par des elements ds: Key Info dans les elements xenc Encrypted- 
Data ; 

La transmission d'une cle symetrique 

Une cle symetrique vehiculee dans le message peut etre transportee par un element xenc : Encrypted- 
Key. II est recommande de referencer cet element par une liste xenc: Ref erenceLi st, surtout si la cle 
doit etre utilisee pour dechiffrer des elements du message. Ce type de mecanisme est particuliere- 
ment utile lorsqu'une cle symetrique generee au hasard et chiffree avec la cle publique du destinataire 
a ete utilisee de la part de l'expediteur pour chiffrer des portions du message. 

Le chiffrement des pieces jointes 

Le chiffrement de pieces jointes (en format MIME, voir chapitre 8) est gere par l'ajout d'elements 
xenc:EncryptedData. Pour chaque piece jointe chiffree : 

• un element xenc : EncryptedData doit etre ajoute (et eventuellement reference par la liste xenc : Ref e- 
renceList) ; 

• le contenu de la piece jointe est remplace par la chaine d' octets resultat du chiffrement ; 

• le type Content-Type de la piece MIME devient application/octet-stream ; 

• le Content-Type original est stocke en tant que valeur de l'attribut /xenc: EncryptedData/ 
@MimeType ; 

• la piece jointe est referencee par un URI de schema cid: (dont la resolution donne la valeur de 
Content-ID de la piece), contenu d'un element /xenc:EncryptedData/xenc:CipherReference. 
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Les procedures 

Un message SOAP chiffre doit etre un message SOAP valide. Cela implique qu'il est interdit de chif- 
frer, avec les mecanismes specifies par WSS-Core, l'enveloppe, l'en-tete et le corps d'un message 
SOAP. En revanche, peuvent etre chiffres les descendants directs de l'en-tete, du corps et les pieces 
jointes. 

La procedure de chiffrement 

La specification recommande des procedures de chiffrement. Par exemple, la procedure recomman- 
dee pour le chiffrement d'un element du message SOAP est la suivante : 

1. Creation du message SOAP en clair. 

2. Creation d'une entree de l'en-tete wsse: Security. 

3. Creation d'un element wsse : Securi ty/xenc : Ref erenceLi st. 

4. Creation d'un element « orphelin » vide xenc: EncryptedData. 

5. Localisation dans le message et chiffrement de l'objet a chiffrer (element, contenu d'un element) 
en conformite avec les regies XML Encryption. 

6. Remplacement de l'objet a chiffrer avec un element xenc: EncryptedData avec en contenu la 
chaine d' octets resultat du chiffrement. 

7. Si le chiffrement repose surunjeton de securite, insertion d'un element wsse : Security TokenRefe- 
rence avec la reference dans l'element /xenc :EncryptedData/ds: Key Info. 

8. Creation d'un element xenc: Data Reference avec une reference a l'element xenc: EncryptedData. 

9. Insertion de l'element xenc:DataReference dans wsse:Security/xenc:Referencel_ist. 

La procedure de dechiffrement 

La procedure de dechiffrement d'un element du message SOAP peut etre resumee ainsi : 

1. Localisation de l'element a dechiffrer xenc:EncryptedData, eventuellement a l'aide de /wsse:Secu- 
ri ty/xenc: Ref erenceLi st. 

2. Dechiffrement du contenu de xenc: EncryptedData en conformite avec les regies XML Encryp- 
tion. 

3. Remplacement de l'objet en clair a la place de xenc: EncryptedData. 

La gestion de la securite avec WSE .NET 

Les services Web developpes avec le framework .NET s'appuient surASP.NET, lequel propose nati- 
vement les quelques mecanismes qui permettent d' assurer la securite au niveau transport pour les 
applications Web (voir chapitre 15) : les technologies SSL/TLS destinees a securiser le protocole 
HTTP. Ces memes mecanismes peuvent etre utilises pour securiser le transport des messages SOAP/ 
HTTP, et done pour obtenir une securite point a point. 

Le Web Service Enhancements 1.0 (WSE) est une extension du framework .NET qui implemente la 
specification WS-Security 1.0. Cette extension, en coherence avec WS-Security, fournit trois fonctions 
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principales pour securiser la transmission des messages SOAP dans des architectures plus complexes 
(securite de bout en bout) : 

• l'integration des informations d' accreditation dans le message SOAP, une technique qui permet 
d'authentifier l'emetteur quel que soit le chemin emprunte par le message ; 

• l'utilisation de signatures arm de garantir l'integrite du message ; 

• le chiffrement qui permet d'assurer la confidentialite des informations transmises. 

Nous allons exposer la mise en ceuvre de ces trois fonctions de securite et illustrer la demarche par 
l'utilisation de l'exemple presente dans le chapitre 15. 



Implementation WSE (voir chapitre 15) : 

Les projets qui doivent acceder aux fonctionnalites de WSE doivent referencer I'espace de noms .NET 

Microsoft. Web. Services. Pour realiser cela, il faut ajouter une reference au projet sur I'assemblage 

Microsoft. Web. Services . dl 1 . 

Pour qu'un emetteur puisse emettre des en-tetes SOAP WS-Security, il est necessaire de modifier la classe proxy 

en la faisant heriter de Mi crosof t . Web . Servi ces . WebServi cesCl i ent Protocol . 

Si une application (recepteur WSE) est censee recevoir des messages possedant des extensions WSE (WS- 

Routing ou WS-Security), elle doit etre configured (web.config) de maniere a pouvoir analyser et traiter ces 

extensions. Sans cette configuration, le recepteur declenche une erreur puisqu'il est incapable de comprendre le 

message SOAP dans sa totalite. 

A noter enfin qu'il existe un utilitaire de configuration pour WSE ( http://msdn.microsoft.com/webservices/building/ 

wse/default.aspx) : il est accessible depuis Visual Studio.NET a partir du menu contextuel du projet situe dans 

I'explorateur de solutions et permet de realiser la plupart des taches de configuration de maniere interactive (voir la 

section dediee a I'interoperabilite Java/.NET en fin de chapitre). 



La gestion des certificats X.509 

WSE permet de gerer la securite sur la base des certificats X.509. 
Rappelons qu'il est possible de se procurer un certificat X.509 : 

• en s'adressant a une autorite de certification exteme, telle que CertiNomis, filiale de La Poste (voir 
http://www.certinomis.com), la societe Verisign (http://www.verisign.com) ou Thawte (http://www.thawte.com) ; 

• en s'adressant a un service interne pouvant emettre des certificats (par exemple a partir d'un 
serveur d'entreprise Windows 2000 Server ou d'un serveur Apache) ; ces certificats peuvent etre 
ou non signes par une autorite de certification. 

Pour qu'un recepteur WSE puisse verifier les certificats qu'il obtient ou qu'il recoit, il doit obtenir ce 
que Ton appelle le chemin d'acces de certification d'une autorite de certification : cette information 
permet au systeme de verifier tous les certificats qui ont ete emis par cette autorite par la validation 
recursive des autorites jusqu'a une racine de confiance. 

La localisation des certificats chez un agent WSE est parametrable dans le fichier de configuration 
web . conf i g au moyen de F element XML X509 . Cet el ement possede quatre attributs : 

• storeLocati on specifie V entrepot dans lequel WSE recherche les certificats a envoyer ou a utiliser 
pour chiffrer des messages ou pour valider des signatures sur des messages re§us. Une application 
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cliente fixe en general cet attribut a CurrentUser et un service Web a Local Machine (valeur par 
defaut: Local Machine). 

• veri fyTrust specifie si WSE doit verifier qu'un certificat recu comme accreditation de Fenvoyeur 
possede un chemin d'acces aboutissant a une autorite de certification racine de confiance (valeur 
par defaut : true). 

• al 1 owTestRoot specifie si WSE doit modifier la procedure de verification pour permettre l'appro- 
bation de certificats signes par une racine de confiance de test (valeur par defaut: f al se). 

• all owRevocati onUrl Retri eval specifie si WSE doit acceder au reseau durant la procedure de veri- 
fication des revocations des certificats ou s'il doit s'appuyer sur le cache (valeur par defaut : true, 
c'est-a-dire acces reseau). 

• al 1 owUrl Retri eval specifie si WSE doit acceder au reseau durant la procedure de construction des 
chemins d'acces des autorites de certification de confiance ou s'il doit s'appuyer sur le cache 
(valeur par defaut : f al se, c'est-a-dire pas d'acces reseau). 

En plus des certificats (les siens et surtout ceux de ses interlocuteurs), un agent WSE doit gerer ses 
cles privies. L' acces a une cle privee est necessaire lorsqu'un agent WSE doit signer un message 
sortant ou dechiffrer un message entrant. Normalement, seul le compte administrateur systeme ou 
celui du proprietaire du certificat dispose des droits d'acces (et surement pas le compte ASP NET de 
ASP.NET). Deux solutions sont done possibles pour permettre cet acces : 

• modifier le compte utilise par defaut parASP.NET (attribut userName de F element processModel du 
fichier machine. config) ; 

• ou bien dormer au compte ASPNET le droit d'acces complet aux fichiers contenant les cles (repertoire 

C:\Documents and Settings\All Users\Appl ication Data\Microsoft\Crypto\RSA\MachineKeys). 

L'authentification 

WSE permet de gerer trois types (ou profils, selon la terminologie WSS-Core) de jetons de securite : 

• les jetons de securite pour les certificats X.509 ; 

• les jetons de securite pour les couples nom d'utilisateur/mot de passe ; 

• des jetons binaires personnalises pour des procedures d' accreditation specifiques. 

Quel que soit le type d' accreditation retenu, le principe de fonctionnement reste identique : la classe 
SoapContext de WSE permet d' acceder a F entree de l'en-tete wsse : Securi ty du message SOAP grace a 
sapropriete Security. Les jetons de securite sont stockes dans la collection Tokens de l'occurrence de la 
classe Security, valeur de la propriete. L'authentification de l'emetteur WSE passe done par l'ajout dans 
cette collection d'un ou de plusieurs jetons de securite qui doivent etre valides par le recepteur. 

Les objets qui constituent cette collection dependent du type d' accreditation mais heritent tous de la 
classe Securi tyToken : 

• la classe UserNameToken permet de gerer des jetons de type nom d'utilisateur/mot de passe 
(wsse:UsernameToken) ; 
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• la classe X509SecurityToken permet de gerer des ceitificats X.509, done des jetons wsse:Binary- 
SecurityToken avec wsse:X509v3 comme valeur de l'attribut ValueType ; 

• la classe abstraite BinarySecurityToken permet de mettre en ceuvre de nouveaux types de jetons 
binaires. 

Espace de noms .NET Mi crosof t . Web . Servi ces . Securi ty 

Les classes Security, SecurityToken, etc. font partie de I'espace de noms .NET Microsoft. Web. Servi- 
ces. Security. 

Lauthentification avec nom d'utilisateur/mot de passe 

Pour s'authentifier aupres d'un recepteur WS-Security a l'aide d'un couple nom d'utilisateur/mot de 
passe, F agent WSE doit done creer un objet d' accreditation de type UserNameToken : 

IUsernameToken userToken = new UsernameToken 
("Mon Login" , "MonPwd" .PasswordOption.SendHashed) ; 

Cet objet permet de gerer le mot de passe de trois manieres : 

• PasswordOption.SendNone : le mot de passe n'est pas transmis dans le message. 

• PasswordOption.SendHashed : Falgorithme de hachage SHA1 est applique au mot de passe et le 
resultat est envoye au recepteur WS-Security. 

• PasswordOption.SendPlainText : le motde passe est envoye en clair, ce qui n'est envisageable que 
si le protocole SSL/TLS est utilise au niveau transport. 

II suffit ensuite au client d'ajouter simplement le jeton de securite au message SOAP, comme le 
montre l'exemple suivant (voir le chapitre 15 pour la base de cet exemple) : 

// Creation des donnees d'accreditation 
UsernameToken userToken - new UsernameToken 

( "Mon Login" , "MonPwd" .PasswordOption.SendHashed) ; 
// creation de 1 'objet proxy 

local host. Macalculatrice myCalc = new local host. Macalculatrice( ) ; 
// recuperation du contexte SOAP (WSE) 
SoapContext requestContext = myCal c.RequestSoapContext; 
// duree de vie du message = 1 mn 
requestContext. Timestamp.Ttl = 60000; 
// ajoute 1 'accreditation au message SOAP 
requestContext. Security. Tokens. Add (userToken) ; 
// appel de la methode du service Web 
int re = myCalc.AdditionO'nt. Parse (TextBoxl.Text) , 

int. Parse (TextBox2.Text) ); 

La prise en charge de ces donnees d'accreditation de la part d'un recepteur WSE est realisee au 
moyen d'une classe qui implemente l'interface IpasswordProvider et fournit une methode GetPass- 
word. 

La methode GetPassword est systematiquement appelee par un recepteur WSE lorsqu'il detecte la 
presence d'un jeton de type nom d'utilisateur/mot de passe (wsse: UserNameToken). Elle lui permet de 
trouver le mot de passe associe au nom d'utilisateur et de le comparer a celui qui est transmis (soit en 
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clair, soit en condense par le biais d'une fonction de hachage). Evidemment, cette methode peut faire 
appel a toutes sortes de techniques plus ou moins complexes pour obtenir ce resultat : base de 
donnees, Active Directory, etc. Exemple : 

using System; 

using Microsoft .Web. Services. Security ; 
using Microsoft .Web. Services; 
namespace WSCal culatrice { 

// attribut de securite 

[ Securi ty Permissi on (SecurityAct ion. Demand, 

Flags=SecurityPermissionFl ag.UnManagedCode)] 

public class PasswordProvider: IPasswordProvidert 
public PasswordProvider( ) { 
} 

// le mot de passe = le login 
public string GetPasswordtUsernameToken userNameH 

return userName.Username ; 
} 



Restriction d'acces de GetPassword 

La methode GetPassword est particulierement critique et son acces doit done etre restreint. Le controle d'acces 
peut etre realise a partir du controle de securite effectue par le CLR et configure par le biais d'attributs, comme 
e'est le cas dans notre exemple. 



II est ensuite necessaire d'indiquer au service Web l'assemblage dans lequel cette methode est imple- 
mentee. L' exemple suivant est le fichier de configuration d'un service Web qui prend en charge des 
accreditations de type nom d'utilisateur/mot de passe : d'un cote, il declare les extensions WSE et de 
1' autre, il localise la methode GetPassword. 

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
<configSections> 

<!-- definit la section microsoft. web. services --> 
<section name= "microsoft. web. services" 
type="Microsoft.Web.Services.Configuration.WebServicesConfiguration, 
Microsoft. Web. Services, Version=l .0.0.0, Culture=neutral , 
PublicKeyToken=31bf3856ad364e35" /> 
</configSections> 
<microsoft.web.services> 

<!-- definit ou est implemented la methode GetPassword --> 
<security> 

<password Provider type=" WSCal culatrice. PasswordProvider, WSCalculatrice"/> 
</security> 
</microsoft. web. services) 
<system.web> 
<!-- prise en charge de WSE --> 
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<webServices> 
<soapExtensionTypes> 
<add type= " Mi crosoft. Web. Services.WebServices Extension, 
Microsoft. Web. Services, Version=l. 0.0.0, Culture=neutral , 
PublicKeyToken=31bf3856ad364e35" priori ty="l" group="0"/> 
</soapExtensionTypes> 
</webServices> 
</system.web> 
</configuration> 

Ces deux seules actions de configuration suffisent pour que le service Web prenne en charge les 
accreditations et les valide. Mais il est cependant necessaire d'ajouter quelques lignes de code 
supplementaires, ne serait-ce que pour verifier la presence obligatoire de ces accreditations. Soit dit 
en passant, ce code pourrait etre genere automatiquement par les outils et les environnement de deve- 
loppement si cette exigence pouvait etre declaree de facon standard dans un document WSDL par un 
formalisme approprie (contrat de securite). Exemple : 

SoapContext requestContext = HttpSoapContext. RequestContext; 
// Verifie que le contexte Soap existe 
if (requestContext != null) { 

// accreditation de type login/mot de passe 

UsernameToken unToken = requestContext. Security as UsernameToken; 

If (unToken != nul 1 ) { 
// verifie 1 'accreditation 

} 
} 

Lauthentif ication avec certif icat X.509 

Pour s'authentifier aupres d'un recepteur WS-Security a l'aide d'un certificat X.509, l'emetteur WSE 
doit creer un objet d' accreditation de type X509SecurityToken. Les certificats sont stockes dans des 
entrepots. Pour obtenir un certificat, l'emetteur WSE doit acceder a un entrepot en particulier, puis 
selectionner un certificat parmi ceux qui s'y trouvent. 

L' objet X509Certi f i cateStore permet d'acceder a ces differents entrepots grace a deux methodes en 
particulier : 

• CurrentUserStore permet d'ouvrir un des entrepots de l'utilisateur courant ; 

• Local Machi neStore permet d'ouvrir un des entrepots de la machine. 

Ces deux methodes attendent en parametre le nom d'un entrepot en particulier. Ce nom est fourni par 
cinq proprietes statiques de l'objet X509Certi f 1 cateStore : 

• CAStore reference l'entrepot ou sont stockes les certificats des autorites de certification racine 
auxquels on ne fait pas confiance directement, ou ceux de subordonnees, editeurs de confiance, etc. 
qui font partie de la hierarchie des chemins d'acces de certification. 

• MyStore reference l'entrepot ou sont stockes les certificats qu'on utilise couramment (de l'utilisateur 
courant, de l'ordinateur, des services auxquels on accede, etc.). 
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• RootStore reference Fentrepot ou sont stockes les certificats des autorites de certification racine 
auxquels on fait directement confiance. Ces certificats sont inverifiables puisqu'ils sont au sommet 
de la hierarchie . 

• TrustStore reference Fentrepot ou sont stockes les certificats des autorites de certification ayant un 
role precis. Par exemple, une autorite qui delivre des certificats pour les e-mails et pour Fauthenti- 
fication, mais dont on n'accepte que les certificats d'e-mails, est placee ici. Si Ton veut accepter 
tout ce qui est emis par cette autorite, alors son certificat doit etre place dans RootStore. 

• UnTrustedStore correspond a Fentrepot ou sont stockes les certificats non valides . 
L' exemple suivant ouvre Fentrepot personnel de Futilisateur courant : 

IX509CertificateStore entrepot; 
entrepot = X509CertificateStore.CurrentUserStore(X509CertificateStore.MyStore) ; 
bool isOpen = entrepot. OpenRead( ) ; 

Les certificats sont accessibles a partir de la collection Certificates de Fobjet X509Certifi- 
cateStore. II est possible de les enumerer ou d'en rechercher un en particulier grace a quatre 
methodes : 

• FindCertificateByHash permet de trouver un certificat a partir de son empreinte numerique (en 
general obtenu grace a Falgorithme SHA1, voir les proprietes d'un certificat) ; 

• FindCertificateByKey Identifier permet de trouver un certificat a partir de la cle publique de 
F autorite de certification ; 

• FindCertificateBySubjectName permet un certificat a partir du nom du sujet certifie ; 

• FindCertificateBySubjectString permet de trouver un certificat a partir d'une partie du nom du 
sujet certifie. 

II suffit ensuite a Femetteur d'ajouter simplement cet objet d' accreditation, emboite dans un jeton de 
securite, au message SOAP, comme le montre Fexemple suivant (voir le chapitre 15 pour la base de 
cet exemple) : 

// ouverture de 1 'entrepot 
X509CertificateStore entrepot; 

entrepot = X509CertificateStore.CurrentUserStore(X509CertificateStore.MyStore) ; 
bool isOpen = entrepot. OpenRead( ) ; 
// recuperation du premier certificat 

X509Certificate certificat = (X509Certificate) entrepot. Certifi cates[0] ; 
// Creation des donnees d'accreditation 

X509SecurityToken X509Token - new X509SecurityToken(certificat) ; 
// creation de 1 'objet proxy 

local host. Macalculatrice myCalc = new local host. Macalculatrice( ) ; 
// recuperation du contexte Soap (WSE) 
SoapContext requestContext = myCalc. RequestSoapContext; 
// duree de vie du message = 1 mn 
requestContext. Timestamp.Ttl = 60000; 
// ajoute 1 'accreditation au message Soap 
requestContext. Security. Tokens. Add (X509Token) ; 
// appel de la methode du service Web 
int re = myCalc. Additiondnt. Parse (TextBoxl.Text) , 
int. Parse (TextBox2.Text) ); 
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Espacedenoms .NET Microsoft. Web. Services. Security. X509 

Les classes X509CertificateStore, X509Certificate, etc. font partie de I'espace de noms .NET Micro- 
soft. Web. Services. Security . X509. 



La prise en charge et la validation de 1'authentification X.509 de la part du recepteur WSE sont reali- 
sees par la configuration du recepteur pour qu'il puisse effectuer les controles de validite des certifi- 
cats recus aupres de chaque autorite de certification emettrice. Cette configuration se fait grace a 
l'element XML X509 du fichier web.config (voir la section « La gestion des certificats X.509 »). 

Les valeurs par defaut de l'element X509 sont generalement suffisantes pour que le recepteur WSE 
prenne en charge automatiquement les validations des accreditations X.509. Cependant, comme dans 
le cas precedent, il est quand meme necessaire d'ajouter quelques lignes de code supplementaires ne 
serait-ce que pour verifier la presence obligatoire d'un certificat (les considerations sur l'utilite d'un 
formalisme WSDL pour declarer les exigences de securite et permettre la generation automatique de 
ce type de code s'appliquent evidemment aussi a la validation X.509). Exemple : 

SoapContext requestContext = HttpSoapContext. RequestContext; 
// Verifie que le contexte Soap existe 
if (requestContext != null) { 

// accreditation de type certificat X509 

X509SecurityToken unToken = requestContext. Security as X509SecurityToken; 

If (unToken != nul 1 ) ( 
// le controle est automatiquement realise par WSE 

} 
) 

La signature 

WSE permet de gerer trois types de signatures, en coherence avec la gestion de 1'authentification : 

• signature a cle asymetrique, les cles publiques etant gerees via les certificats X.509 ; 

• signature par secret partage, sur la base du couple nom d'utilisateur/un mot de passe ; 

• mecanismes de signature specifiques, programmes par le developpeur WSE. 

La signature (d'une partie) d'un message implique obligatoirement 1' utilisation des donnees d' accre- 
ditation (les jetons de securite) que nous avons decrit dans la section precedente. II s'agit done de 
creer, en fonction de l'approche retenue : 

• soit un objet X509Securi tyToken ; 

• soit un objet UserNameToken ; 

• soit encore un objet (heritant de) BinarySecuri tyToken, qui implemente un mecanisme d'accredi- 
tation particuliere. 

Ensuite, il faut inscrire l'objet d' accreditation cree comme un jeton de securite dans l'en-tete du 
message SOAP (SoapContext. Security. To kens). En ce qui concerne les certificats X509, il est neces- 
saire de verifier que le certificat puisse etre utilise pour signer. La propriete SupportDi gi tal Si gnature 
de l'objet X509Certificate permet de s'en assurer. 
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Une fois cette etape realisee, la signature du message consiste d'abord a creer un objet Signature en 
passant en parametre du constructeur F objet d' accreditation. Exemple : 

Signature maSignature = new Signature(X509Token) ; 

II faut ensuite ajouter la signature comme element wsse: Signature dans F entree de Fen-tete 
wsse:Security du message SOAP : Fobjet Security possede une collection Elements destinee a 
recevoir des objets (interface I securi ty El ement) comme les signatures ou les elements de description 
du chiffrement. 

L' exemple suivant ajoute une signature de type nom d'utilisateur/mot de passe : 

// Creation de la signature 

Signature maSignature = new Signature(UsernameToken) ; 
// enregistrement de la signature dans le message SOAP 
requestCon text. Security. Elements. Add (ma Signature) ; 

Cote recepteur WSE, le travail a accomplir a deja ete partiellement decrit dans la section precedente : 
une fois le recepteur WSE configure pour recevoir et verifier des donnees d' accreditation, il est pret a 
valider les signatures presentes dans le message SOAP. Cette validation est realisee automatiquement 
par WSE avant meme que le code du service invoque s'execute. 

La validation d'une signature realisee a Faide d'un certificat X.509 de la part d'un recepteur WSE est 
realisee pratiquement automatiquement et sans parametrage particulier. L'emetteur WS-Security 
signe le message a Faide de sa cle privee ; le recepteur WSE extrait le certificat du message et verifie 
la signature a Faide de la cle publique fournie par le certificat : aucune configuration particuliere 
n'est requise pour cette etape de verification. 

En revanche, le certificat lui-meme peut etre verifie et WSE doit dans ce cas pouvoir acceder aux 
chemin d'acces de certification ainsi qu'aux certificats des autorites de certification racine de 
confiance (voir la section « La gestion des certificats X.509 »). 

Lorsque la signature est realisee a Faide d'une accreditation de type nom d'utilisateur/mot de passe, 
il n'est evidemment pas necessaire de transmettre de mot de passe (PasswordOption.SendNone), a 
condition bien sur que le recepteur Fait deja (le passwordProvider du recepteur doit etre capable de 
lui fournir). 

Quels sont les elements du message qu'il est possible de signer ? Par defaut, WSE signe le contenu 
de Felement Body du message ainsi que les elements d'en-tete Created et Expi res (WS-Timestamp) et 
les elements Action, To, Id et From (WS-Routing). 

La propriete SignatureOptions de Fobjet Signature permet a l'emetteur WSE de preciser quels 
elements doivent etre signes, et au recepteur WSE de localiser les parties signees, au moyen des 
valeurs d'une enumeration : 

• Incl udeNone specifie qu' aucune partie du message n'est signee ; 

• Incl udePath specifie que Felement path de Fen-tete de routage est signe ; 

• Incl udePathAction specifie que le sous-element action de Felement path de Fen-tete de routage 
est signe ; 

• Incl udePath From specifie que le sous-element from de Felement path de Fen-tete de routage est 
signe ; 
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Incl udePathld specifie que le sous-element id de Felement path de Fen-tete de routage est signe ; 

Incl udePathTo specifie que le sous-element to de Felement path de Fen-tete de routage est signe ; 

Incl udeSoapBody specifie que le corps du message est signe ; 

Incl udeTimestamp specifie que la duree de vie du message est signee ; 

Incl udeTimestampCrea ted specifie que Felement wsu: Created est signe ; 

Incl udeTimestampExpi res specifie que Felement wsu: Expi res est signe. 

Nous signalons (sans detailler) qu'il est aussi possible, par le meme mecanisme, de signer et valider 
des entrees de Fen-tete. 

L'exemple suivant montre comment tester si le corps du message est signe : 

foreach (ISecurityElement securityElt in soapContext. Security. Elements) { 
if (securityElt is Signature) { 
Signature maSignature = securityElt as Signature; 
bool isSigned = ( (maSignature. SignatureOptions & 
SignatureOptions . Incl udeSoapBody) != 0); 
} 
} 

Le chiffrement 

WSE permet de chiffrer les (parties des) messages SOAP en utilisant deux methodes classiques : 

• le chiffrement a cle asymetrique, qui consiste a utiliser une paire de cles publique/privee (comme 
le permettent les certificats X.509) ; 

• le chiffrement a cle symetrique, qui consiste a utiliser un code secret connu de Femetteur et du 
recepteur. 

Par defaut, c'est le contenu exhaustif de Felement Body du message qui est chiffre, mais il est evidem- 
ment possible de chiffrer n'importe quel element du message. La seule exception concerne les 
elements contenus dans Fentete Security. 

Le chiffrement a cle asymetrique a I'aide d'un certificat X.509 

Le chiffrement d'un document est realise par Femetteur a Faide de la cle publique du certificat X.509 
du recepteur ; le dechiffrement est ensuite realise par le recepteur a Faide de sa cle privee correspon- 
dant a la cle publique utilisee. Rappelons que cette methode permet de chiffrer mais ne permet pas 
d'authentifier en meme temps le producteur du document chiffre (cette authentication doit etre 
accomplie par des moyens additionnels). 

II est done necessaire que Femetteur WSE ait acces au certificat du recepteur WS-Security et que, a 
Finverse, le recepteur WSE, en Foccurrence ASP.NET, ait les droits d'acces sur la cle privee corres- 
pondant a son propre certificat utilise par Femetteur WS-Security (ces deux problemes sont resolus 
par une configuration appropriee des environnements WSE). 

Pour Femetteur WSE, le choix du certificat du recepteur WS-Security qu'il va utiliser pour chiffrer le 
message est inevitablement realise par le code applicatif. Pour le recepteur WSE, F analyse du 
message chiffre, F identification de son certificat utilise par Femetteur WS-Security, la recherche de 
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la cle privee coiTespondante et finalement le dechiffrement sont realises automatiquement par le code 
WSE correctement parametre. 

Pour resumer : 

• Les agents WS-Security doivent disposer des certificats des interlocuteurs respectifs pour pouvoir 
chiffrer les messages. lis peuvent evidemment s'echanger les certificats respectifs et ce transfert 
peut etre realise en effectuant un premier echange de messages signes, les certificats utilises pour 
la signature etant ensuite utilises pour chiffrer les messages suivants. 

• L'emetteur WSE choisit le certificat du recepteur WS-Security qu'il veut utiliser pour chiffrer le 
message ; le certificat choisi doit pouvoir prendre en charge le chiffrement des donnees, la 
propriete SupportDataEncryption de l'objet X509Certificate permet de s'en assurer. 

• Le fichier web.config (element X509) doit etre correctement configure afin de permettre au recep- 
teur WSE d'identifier parmi ses certificats celui qui est utilise par l'emetteur WS-Security pour 
chiffrer le message. 

• Le recepteur WSE doit avoir un droit d'acces systeme a la cle privee correspondant au certificat 
utilise par l'emetteur WS-Security. 

Voici un exemple d'obtention d'un certificat du recepteur WS-Security : 

// ouverture du entrepot 

X509CertificateStore entrepot; 

entrepot = X509CertificateStore. Local MachineStore(X509CertificateStore.MyStore) ; 

bool isOpen = entrepot. OpenRead( ) ; 

// recuperation du premier certificat 

X509Certificate certificat = (X509Certificate) entrepot. Certifi cates[0] ; 

// Creation des donnees d'accreditation 

X509SecurityToken X509Token = new X509SecurityToken(certificat) ; 

// ajoute 1 'accreditation au message SOAP 

requestCon text. Security. Tokens. Add (X509Token) ; 

II suffit ensuite de creer un objet EncryptedData et de l'inclure dans l'objet Security comme nous 
l'avons fait pour les signatures. Cela va se traduire par l'inclusion de F element wsse: EncryptedData 
dans F entree de l'en-tete du message SOAP wsse: Security. Exemple : 

I EncryptedData cryptage = new EncryptedData (X509Token); 
requestCon text. Security. Elements. Add (crypt age) ; 

Le chiffrement a cle symetrique 

Le chiffrement a cle symetrique consiste a utiliser une seule cle secrete, connue par l'emetteur et le 
recepteur, pour chiffrer et dechiffrer le message. 

La procedure de chiffrement d'un emetteur WSE doit comprendre la creation d'un objet Encrypted- 
Data et l'inclusion de l'objet dans le message SOAP, ce qui doit etre realise a l'aide de la meme 
procedure que celle utilisee pour le chiffrement asymetrique. Exemple : 

I EncryptedData cryptage = new EncryptedData (made); 
requestCon text. Security. Elements. Add (crypt age) ; 
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WSE permet la creation a la volee d'une cle symetrique. Pour chiffrer (des parties d') un message 
SOAP a Faide de cette technique, il faut d'abord creer un objet EncryptionKey et lui affecter une 
chaine de caracteres qui sera utilisee par WSE pour generer la cle de chiffrement du message. Le 
framework .NET fournit un certain nombre de classes dans Fespace de noms .NET System. Secu- 
rity. Cryptography qui mettent en ceuvre plusieurs algorithmes de generation de cles de chiffrement 
a partir d'un code secret partage. L'exemple suivant montre la generation d'une cle symetrique a 
partir de l'algorithme Triple DES : 

private EncryptionKey GetEncryptionKey( string identifiant, 

byte[] keyBytes /* code secret */, 

byte[] ivBytes /* vecteur Triple DES */) 
{ 

SymmetricAl gorithm algo - new TripleDESCryptoServiceProvider( ) ; 
// initialise Triple DES. 
algo. Key = keyBytes; 
algo. IV = ivBytes; 
// genere la cle de cryptage 

SymmetricEncryptionKey key = new SymmetricEncryptionKey(algo, algo. Key) ; 
KeylnfoName keyName = new KeyInfoName( ) ; 
keyName. Val ue = identifiant; 
key. KeyInfo.AddClause( keyName) ; 

return key; 
} 

Bien evidemment, la methode qui genere la cle de cryptage doit etre implementee chez l'emetteur et 
le recepteur (secret partage). 

Un exemple d'interoperabilite en J2EE et .NET 

Dans cette section, nous allons presenter, dans le cadre de WS-Security 1.0, l'utilisation des imple- 
mentations d'XML Signature pour signer des messages SOAP echanges entre applications J2EE et 
.NET En fait, nous allons mettre en ceuvre une double implementation d'un service Web (en J2EE 
et en .NET) et 1' implementation d'un couple de clients (J2EE et .NET) capables d'invoquer indiffe- 
remment les deux implementations du service. 

La mise en ceuvre de cet exemple s'appuie sur les produits suivants : 

• Microsoft framework .NET 1.0 (http://www.microsoft.com/netframework/default.asp) ; 

• Microsoft Web Services Enhancements (WSE) 1.0 for .NET (http://msdn.microsoft.com/library/ 
default.asp?url=/downloads/list/websrv.asp) ; 

• Java 2 Platform, Standard Edition (J2SE) 1.3.1 (http://java.sun.eom/j2se/1.3) ; 

• Apache Tomcat 4.0.6 (http://jakarta.apache.Org/builds/jakarta-tomcat-4.0/release) ; 

• IBM Web Services ToolKit (WSTK) 3.3.2 (http://www.alphaworks.ibm.com/tech/webservicestoolkit). 

Cette mise en ceuvre est derivee des exemples presentes dans les produits Microsoft Web Services 
Enhancements (WSE) 1.0 for .NET et IBM Web Services ToolKit (WSTK) 3.3.2. 
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L'exemple illustre ici est constitue de services Web de cotation de valeurs boursieres, ecrits en langages 
C# et Java et invoques alternativement par des clients de ce service, egalement rediges en langages C# 
et Java. Chaque client utilise F implementation de WS-Security et XML Signature de la plate-forme 
sous-jacente afin de signer la requete d' invocation du service Web accede et de garantir ainsi le fait que 
le contenu (non chiffre) du message n'a pas ete altere durant F operation. Le message est signe a l'aide 
de la cle privee qui correspond a un certificat numerique X509 fourni par Futilisateur du logiciel client. 

Le niveau d'interoperabilite verifie par l'exemple est la capacite, pour chacune des implementations, 
de comprendre et de valider le message signe par 1' autre. 

Serveur .NET 

Le code du serveur .NET peut etre ecrit a l'aide d'un editeur de textes et compile avec les outils du 
framework. Avec l'environnement de developpement VisualStudio .NET, il faut creer un nouveau 
projet Visual C# de type « ServiceWebASP.NET » nomme WSS-Signatureparexemple. Laclassepar 
defaut Servicel.asmx peut etre renommee StockQuotationService.asmx. 

Cette classe ne comporte qu'une seule methode GetQuote exposee. Elle se presente ainsi : 

using Microsoft .Web. Services; 

using Microsoft .Web. Services. Security ; 

using System; 

using System. ComponentModel ; 

using System. Web. Services; 

using System. Web. Services. Protocols ; 

using System. Xml ; 

namespace WSS_Signature { 

[WebServicet Names pace=" urn :WSS-Signatu re")] 
public class StockQuotationService : WebService { 
public StockQuotationService( ) { 
//CODEGEN: This call is required by the ASP.NET Web Services Designer 
Initial izeComponentt ) ; 
} 

//region Component Designer generated code 

//Required by the Web Services Designer 
private IContainer components = null; 

/// <summary> 

/// Required method for Designer support - do not modify 

/// the contents of this method with the code editor. 

/// </summary> 

private void Initial izeComponentt ) { 

) 
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III <summary> 

/// Clean up any resources being used. 

/// </summary> 

protected override void Dispose( bool disposing ) ( 

if (disposing && components != null) { 
components . Dispose ( ) ; 

} 

base. Dispose (disposing) ; 
} 

#endregion 

[WebMethod] 

public float GetQuote(string symbol) { 

// Verification de la presence du contexte SOAP. 
SoapContext requestContext = HttpSoapContext.RequestContext; 
if (requestContext == null) { 
throw new ApplicationException( 

"Seules les requites SOAP sont acceptees. ") ; 
} 

// Verification des informations de securite du contexte SOAP, 
if (!IsValid(requestContext)) { 
throw new SoapException( 

"Les informations de securite recues sont incorrectes. " , 
new XmlQual ifiedNameC'Bad.Security" , " urn :WSS- Signature")) ; 



return 55.25F; 



) 



private bool IsVal idtSoapContext context) { 
// Verification de la presence d'un jeton de securite. 
if (context. Security. Tokens. Count == 0) { 
return false; 



bool valid = false; 
// Recherche d'une signature valide. 
for (int i = 0; 
valid == false && i < context. Security. Elements. Count; i++) { 
Signature signature = context. Security. Elements[i ] as Signature; 
// Signature utilisee pour signer le corps SOAP ? 
if (signature != null && (signature. SignatureOptions 
& SignatureOptions. IncludeSoapBody) != 0) { 
X509SecurityToken x509token = signature. SecurityToken 

as X509SecurityToken; 
if (x509token != null ) { 
// Verification des autorisations associees (ici, on considere que 
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II tous les acces sont permis, quel que soit le certificat utilise) 
valid = true; 



return valid; 



) 



Pour pouvoir compiler la classe, il faut ajouter un assemblage aux references par defaut integrees lors 
de la creation du projet. Cet assemblage est disponible sous forme d'une DLL : Microsoft.Web.Servi- 
ces.dll (version 1.0.0.0). Lajout est realise automatiquement lors de l'utilisation du menu de parame- 
trage de WSE (cliquer avec le bouton droit de la souris sur le projet WSS-Si gnature dans la fenetre de 
l'explorateur de solution). Ce menu affiche Fecran presente figure 19-8 : 



Web Services Enhancements Settings | 






General Security J Customized filters j Routing J Diagnostic | 






W Enable this project for Web Services Enhancements 1 .0 

Checking this box will add a reference to Microsoft. Web. Services. dll library to 
this project. Web References that are added to or updated in this project will 
be WSE enabled, Unchecking this item will remove this reference as well as 
WSE related settings from the configuration file; Web References will need to 
be manually updated to remove the WSE dependencies. 

p' Enable Microsoft Web Services Enhancement Soap Extensions 

This will add the WSE SOAP Extension to this project. This is only applicable 
to ASP.NET projects. 












OK 


Cancel 









Figure 19-8 

Ecran de parametrage de Microsoft Web Services Enhancements (WSE). 
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Dans cet ecran, il faut cocher les deux choix presentes : le premier choix rend le projet compatible 
WSE et ajoute le nouvel assemblage et le second choix permet d'acceder aux extensions SOAP. Dans 
l'onglet Securi te, il faut egalement decocher le choix Veri f i er 1 a conf 1 ance arm d'eviter le controle 
de la chaine de certificats et de permettre ainsi l'utilisation de simples certificats X509 de test. 

L'utilisation de cet ecran modifie automatiquement le fichier Web. conf ig du projet qui se presente 
ainsi : 

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
<configSections> 
<section 
name= "microsoft. web. services" 

type= " Mi c rosof t. Web. Services. Conf igu rati on. WebServicesConfigurat ion, 
Microsoft. Web. Services, Version=l. 0.0.0, Cul ture=neutral , 
Publ i cKeyToken=31bf 3856ad364e35" /> 
</configSections> 
<system.web> 
Compilation defaul tl_anguage="c#" debug="true" /> 
<customErrors mode="RemoteOnly" /> 
<authentication mode="Windows" /> 
<trace enabled="fal se" requestLimit="10" pageOutput="false" 

traceMode="SortByTime" loca!Only="true" /> 
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0. 1:42424" 
sqlConnectionString="data source=127.0.0.1;user id=sa; 
password=" cookieless="false" timeout="20" /> 
<globalization requestEncoding="utf-8" responseEncoding="utf-8" /> 
<webServices> 
<soapExtensionTypes> 
<add 
type="Mi c rosof t. Web. Services. WebServices Extension, 
Microsoft. Web. Services, Version=l. 0.0.0, Cul ture=neutral , 
PublicKeyToken=31bf3856ad364e35" priority="l" group="0" /> 
</soapExtensionTypes> 
</webServices> 
</system.web> 
<mi crosof t . web . servi ces> 
<security> 

<x509 verifyTrust="false" /> 
</security> 
</mi crosof t. web. servi ces> 
</configuration> 

Par rapport au fichier de configuration standard, les elements configSections, webServices et micro- 
soft, web. services ont ete ajoutes. 
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Ail final, le projet serveur WSS-Signature se presente tel que l'illustre la figure 19-9 



Solution Ewplorer - WSS-Siqna 
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Figure 19-9 

Projet serveur .NET WSS-Signature. 
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Client .NET 



Le client .NET peut egalement etre ecrit a l'aide d'un editeur de textes et compile avec les outils du 
framework. Avec l'environnement de developpement VisualStudio.NET, il faut creer un nouveau 
projet Visual C# de type « Application Console » nomme WSS-Signature-client par exemple. La 
classe pardefaut Classl.cs peut etre renommee Signer.cs. 

Cette classe est chargee de l'invocation de la seule methode GetQuote exposee par chacun des 
serveurs (.NET et Java). Elle se presente ainsi : 

using Microsoft .Web. Services; 

using Microsoft .Web. Services. Security ; 

using Microsoft. Web. Services. Security .X509; 

using System; 

using System. Text; 

using System. Web. Services. Protocols ; 

namespace WSSSignature { 

class Signer ( 
string symbol ; 
string subjectName; 
string implementation; 

Signer(string[] args) { 
symbol = args[0] ; 
subjectName = args[l] ; 
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implementation = null ; 
if (args. Length ™ 3) { 
implementation = args[2]; 



[STAThread] 

static void Main(string[] args) { 
Signer signer = null; 
try { 

signer = new Signer(args) ; 
if (signer. implementation == "WSE") { 
signer. Si gnWSEC ) ; 
return; 
} 

if (signer. implementation == "WSTK") { 
signer. Si gnWSTK( ) ; 
return; 
} 

signer. SignWSE( ) ; 
signer. Si gnWSTK( ) ; 
} 

catch (Exception e) { 
Console. Write Li ne(e.StackTrace) ; 

Console. WriteLine( "\nL'un des parametres est incorrect ou absent."); 
return; 



private void SignWSEO { 
Console. WriteLine("\nSignature et invocation du service Web .NET..."); 

// Creation d'une instance du proxy-service WSE. 

ProxyWSE proxyWSE = new ProxyWSEO; 

SoapContext requestContext = proxyWSE. RequestSoapContext ; 

// Recuperation du jeton de securite X509. 
X509SecurityToken token = GetSecurityToken(subjectName) ; 
if (token == nul 1 ) { 
throw new ApplicationExceptionC'Pas de cle de signature trouvee."); 



// Ajout de la signature a la requete SOAP. 
requestContext. Security .Tokens. Add (token) ; 
requestContext. Security .Elements. Add (new Signature (token) ) ; 
requestContext. Path. MustUnderstand = false; 

// Invocation du service Web .NET. 

Console. WriteLine("\nInvocation de : {0}", proxyWSE. Url ) ; 

float value = proxyWSE. GetQuote(symbol ) ; 
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II Affichage du resultat de 1 'invocation, 
string message - string. Format("{0} : {1}", symbol, value); 
Console. WriteLineC'Valeur de 1 'action {0}", message); 
} 

private void SignWSTKO { 
Console. Writel_ine("\nSignature et invocation du service Web Java..."); 

// Creation d'une instance du proxy-service WSTK. 

ProxyWSTK proxyWSTK = new ProxyWSTKO; 

SoapContext requestContext = proxyWSTK. RequestSoapContext; 

// Recuperation du jeton de securite X509. 
X509SecurityToken token = GetSecurityToken(subjectName) ; 
if (token == nul 1 ) { 

throw new Appl icationException( "Pas de cle de signature trouvee."); 
} 

// Ajout de la signature a la requete SOAP. 
requestContext. Security .To kens. Add (to ken) ; 
requestContext. Security .Elements. Add (new Signature (to ken) ) ; 
requestContext. Path. MustUnderstand = false; 

// Invocation du service Web Java. 

Console. Writel_ine("\nInvocation de : (0}", proxyWSTK. Url ) ; 

float value = proxyWSTK. getQuote( symbol ) ; 

// Affichage du resultat de 1 'invocation, 
string message = string. Format("{0} : {1}", symbol, value); 
Console. WriteLineC'Valeur de 1 'action {0}", message); 
} 

X509SecurityToken GetSecurityToken(string subjectName) { 
X509SecurityToken securityToken; 

// Ouverture de 1 'entrepot de certificats de 1 'util isateur. 
X509CertificateStore store = X509CertificateStore.CurrentUserStore( 

X509CertificateStore.MyStore); 
store. 0penRead( ) ; 

try { 
// Recherche du certificat selectionne par 1 'util isateur. 
X509Certificate certificate; 
X509CertificateCollection matchingCerts = 

store. FindCertificateBySubjectSt ring (subjectName) ; 
if (matchingCerts. Count == 0) { 

throw new Appl icationException("Aucun certificat trouve, associe au 
nom de 1'objet passe en parametre. " ) ; 
} 
else { 

certificate = matchingCerts[0] ; 
) 
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II Le certificat est-il adequat pour la signature numerique ? 
if ( 'certificate. SupportsDigitalSignature || certificate. Key == null)) 
throw new Appl icationExceptiont 

"Le certificat choisi ne supporte pas les signatures numeriques 
ou ne dispose pas d'une cle privee."); 
} 

else { 
byte[] keyld = certificate. GetKeyIdentifier( ) ; 
Console. WriteLine("\nObjet du certificat choisi : {0}", 

certificate.GetName( ) ) ; 
Console. WriteLineC'Identificateur de la cle : {0}", 

Convert. ToBase64St ring (key Id) ) ; 
Console. WriteLineC'Cle publique : {0}", 

certificate. GetPubl icKeyString( ) ) ; 
securityToken - new X509SecurityToken(certificate) ; 



finally ( 
if (store != nul 1 ) { 
store. Closet ) ; 



return securityToken; 
} 
} 
) 

La classe Si gner . cs necessite deux parametres (minimum) ou trois parametres a 1' execution : 

• Le premier parametre (obligatoire) coiTespond au code de la valeur boursiere (chaine de carac- 
teres) dont on veut obtenir la cote : IBM ou MSFT, par exemple. 

• Le second parametre (obligatoire) est le nom de l'objet du certificat X509 a rechercher dans 
F entrepot de certificats de Futilisateur (champ Common Name CN). 

• Le troisieme parametre (facultatif) precise quel service Web invoquer : WSE signifie que le client 
doit s'adresser au serveur .NET, WSTK correspond au serveur Java et toute autre valeur (ou 
aucune valeur) provoque Finvocation successive des deux serveurs. 

La classe Si gner . cs fait appel aux services de deux proxy-services : 

• La classe ProxyWSE . cs permet d'invoquer le serveur .NET. Elle s'obtient en ajoutant au projet une 
reference Web au service dont la description WSDL est accessible a 1' adresse http://localhost:80/WSS- 
Signature/StockQuotationService.asmx?WSDL Lorsque la reference a ete integree au projet, il faut 
ajouter le fichier genere Reference.es du sous-repertoire Web References au projet (menu Ajouter 
qui apparait suite aunclic al'aidedu bouton droit de la souris surle projet WSS-Signature-Client 
dans la fenetre de Fexplorateur de solution), puis le renommer en ProxyWSE.cs. 

• La classe ProxyWSTK.es autorise Finvocation du serveur Java. Elle est obtenue en ajoutant au projet 
une reference Web au service dont la description WSDL est accessible a F adresse http://local- 
host:8080/wstk/wss-signature/services/SignatureStockQuoteService?WSDL Lorsque la reference a ete 
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integree au projet, il faut ajouter le fichier genere Reference . cs du sous -repertoire Web References 
ail projet, puis le renommer en ProxyWSTK.es. 

La classe ProxyWSE.cs se presente ainsi : 

// 

// <autogenerated> 



// 
// 
// 
// 
// 



This code was generated by a tool. 
Runtime Version: 1.0.3705.209 

Changes to this file may cause incorrect behavior and will be lost if 
the code is regenerated. 



// </autogenerated> 
// 



// 

// This source code was auto-generated by Microsoft. VSDesigner, Version 1.0.3705.209. 

// 

namespace WSSSignature { 

using Microsoft. Web. Services; 

using System; 

using System. ComponentModel ; 

using System. Diagnostics; 

using System. Web. Services; 

using System. Web. Services. Description; 

using System. Web. Services. Protocol s; 

using System. Xml .Serial iza t ion; 

/// <remarks/> 

[ DebuggerStepTh rough Attributet )] 

[DesignerCategoryAttributeC'code")] 

[WebServiceBindingAttribute(Name="StockQuotationServiceSoap" , 

Namespace="urn:WSS-Signature")] 
public class ProxyWSE : WebServicesClientProtocol { 

/// <remarks/> 
public ProxyWSEO { 
this.Url = 

"http:// local host:80/WSS-Signature/StockQuotationService.asmx" ; 
} 

/// <remarks/> 
[SoapDocumentMethodAttribute("urn:WSS-Signature/GetQuote" , 

RequestNamespace="urn:WSS-Signature" , 

ResponseNamespace=" urn :WSS -Signature" , Use=SoapBindingllse. Literal , 

Pa rameterStyle=SoapParameterStyle. Wrapped)] 

public Single GetQuote(string symbol) { 
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object[] results = this. InvokeC'GetQuote" , new object[] {symbol}); 
return ( (Single) (results[0] )) ; 



/// <remarks/> 

public IAsyncResult BeginGetQuote(string symbol, AsyncCallback callback, 

object asyncState) { 

return this.BeginInvoke( "GetQuote" , 
new object[] {symbol), callback, asyncState); 



/// <remarks/> 

public Single EndGetQuote( IAsyncResult asyncResult) 

object[] results = this. EndInvoke(asyncResul t) ; 

return ( (Single)(resul ts[0]) ) ; 

) 



} 

) 

L'espace de noms a ete modifie et fixe a la valeur WSSSi gnature, de meme que le nom de la classe et 
le constructeur ont ete changes et alignes sur le nouveau nom de la classe (ProxyWSE). 

La classe ProxyWSTK.es se presente ainsi : 



// 

// <autogenerated> 



// 
// 
// 
// 
// 



This code was generated by a tool. 
Runtime Version: 1.0.3705.209 

Changes to this file may cause incorrect behavior and will be lost if 
the code is regenerated. 



// </autogenerated> 
// 



// 

// This source code was auto-generated by Microsoft. VSDesigner, Version 1.0.3705.209. 
// 

namespace WSSSignature { 
using Microsoft. Web. Services; 

using System; 

using System. ComponentModel ; 

using System. Diagnostics; 

using System. Web. Services; 

using System. Web. Services. Description; 

using System. Web. Services. Protocols; 

using System. Xml .Serial izati on; 

/// <remarks/> 

[DebuggerStepThroughAttribute( )] 
[DesignerCategoryAttributet "code" )] 

[WebServiceBindingAttribute(Name="SignatureStockQuoteServiceSoapBinding" , 
Namespace= 
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"http: //local host/wstk/wss-signature/services/SignatureStockQuoteService")] 
public class ProxyWSTK : WebServicesCl ientProtocol { 

/// <remarks/> 
public ProxyWSTKO { 

this.Url = "http: //local host :80807wstk/wss -signature/services/ 

*»SignatureStockQuoteService" ; 
} 

/// <remarks/> 
[SoapRpcMethodAttributeC" , 

Request Namespace=" http: //local host :8080/wstk/wss -signature/services/ 

*»SignatureStockQuoteService". 

ResponseNamespace=" http: //local host/wstk/wss-signature/services/ 

*»SignatureStockQuoteService" )] 
[return: SoapElementAttributet "getQuoteReturn")] 
public Single getQuote(string inO) { 

object[] results = this. InvokeC'getQuote" , new object[] { i n } ) ; 

return ((SingleMresul ts[0]) ) ; 
} 

/// <remarks/> 

public IAsyncResult BegingetQuotetstring inO, AsyncCallback callback, 

object asyncState) { 

return this.Beginlnvoket "getQuote" , new object[] { i n } , callback, 
asyncState) ; 
} 

/// <remarks/> 

public Single EndgetQuotet System. IAsyncResult asyncResult) { 

object[] results = this.EndInvoke(asyncResul t) ; 

return ((SingleMresul ts[0]) ) ; 



) 

L'espace de noms a aussi ete modifie et fixe a la valeur WSSSignature, de meme que le nom de la 
classe et le constructeur ont ete changes et alignes sur le nouveau nom de la classe (ProxyWSTK). 

Pour pouvoir compiler le projet, il faut egalement ajouter 1' assemblage Microsoft. Web.Servi- 
ces.dll (version 1.0.0.0). L'ajout se fait automatiquement lorsque Ton utilise le menu de parame- 
trage de WSE (clic a l'aide du bouton droit de la souris sur le projet WSS-Signature-Client dans 
la fenetre de l'explorateur de solution). Dans l'ecran affiche (figure 19-8), il faut simplement 
cocher le premier choix, ce qui rend le projet compatible WSE et ajoute automatiquement le 
nouvel assemblage. 
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Au final le projet serveur WSS-Signature-Cl ient se presente tel que Fillustre la figure 19-10 : 



Solution Explorer - WSS-Signature-Client 
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Figure 19-10 

Projet client .NET WSS-Signature-Client. 



Afin de fournir le second parametre (le nom de l'objet du certificat X509 a rechercher dans 1' entrepot 
de certificats de Futilisateur) necessaire au fonctionnement de la classe Signer.cs, il faut disposer 
d'un tel certificat. Le framework .NET comporte deux outils (situes dans le repertoire C:\Program 
Files\Microsoft Visual Studio .NET\FrameworkSDK\Bin) qui permettent de gerer de tels certificats : 

• certmgr . exe, un outil de gestion graphique des certificats (voir les parametres d'utilisation de cet 
utilitaire a 1' adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htmlfc^ 
temanagertoolcertmgrexe.asp) ; 

• makecert . exe, 1' outil de creation de certificats de test (voir les parametres d'utilisation de cet utili- 
taire a F adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htmlfc^ 
tiontoolmakecertexe. asp) . 

Cependant, selon la FAQ de Faide du produit Web Services Enhancements de Microsoft, l'outil make- 
cert. exe de la version 1.0 du framework .NET n'est pas adapte a la creation de certificats de test 
pouvant etre utilises pour la signature numerique. Pour mettre en ceuvre cet outil, il faut disposer du 
framework 1.1. Une autre solution consiste a utiliser les services de certificats de Windows 2000 pour 
creer sa propre autorite (CA) capable de signer des certificats. Malheureusement, ces services ne sont 
disponibles que sur les versions Server de Windows 2000. La derniere solution, si Ton ne dispose pas 
d'un tel certificat acquis aupres d'une autorite commerciale, telle que VeriSign par exemple, consiste 
a telecharger un certificat de test a partir du site de l'une de ces societes. Un tel certificat (valable 
uniquement a des fins de test et d' evaluation) peut, par exemple, etre obtenu gratuitement aupres de 
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l'autorite de certification CertiNomis, filiale de La Poste (voir http://www.certinomis.com). Une fois tele- 
charge, le certificat est visible dans le navigateur (Outi Is/Options Internet/onglet Contenu/bouton 
Certificats pour Internet Explorer 5.0 et plus). II peut aussi etre visualise via la console MMC 

(Console/Ajouter/Supprimer un composant logiciel enfichable.../bouton Ajouter/choix Certificats). 

Client et serveur Java 

Le client et le serveur Java peuvent etre ecrits a l'aide d'un editeur de textes et compiles avec les outils 
du SDK J2SE. Sous le repertoire C : \wstk-3 . 3\servi ces\demos, il faut creer un nouveau sous-repertoire 
nomme wss -signature par exemple. Dans ce repertoire de projet, il faut creer quatre sous-repertoires : 

• cl 1 ent, qui contient lui-meme un sous-repertoire WSSSi gnature dans lequel sera installee la classe 
Signer. Java, cliente du service Web ; 

• common, qui contient l'entrepot de certificats keystore . db de type JKS ; 

• depl oyment, qui stocke les descripteurs de deploiement WSDD Axis (installation et desinstallation) ; 

• webapp, qui contient un sous -repertoire WEB-INF, sous lequel se trouve le sous-repertoire classes 
dans lequel sera installee la classe d' implementation du service Web StockQuotationService. Java. 

Le service Web Java est tres simple. Voici le code de la classe correspondante StockQuotationSer- 
vice. Java : 

public class StockQuotationService { 

public float getQuote(String symbol) throws Exception { 
return 55.25F; 

) 
} 

La classe du client Signer. Java se presente ainsi : 

package WSSSignature; 

import com.ibm.wstk.axis.cl ient .WSTKService; 
import com.ibm.wstk.WSTKConstants; 

import Java. net. URL; 

import javax.xml . namespace. QName; 

import javax.xml .rpc.ParameterMode; 

import org. apache. axis.cl ient. Service; 
import org. apache. axis.cl ient.Cal 1 ; 

public class Signer { 

String symbol ; 

String implementation; 

public Signer(String[] args) { 
symbol = argsLO]; 
implementation = "ALL"; 
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if (args. length == 2) { 
implementation = args[l]; 



) 



public static void main(String[] args) { 
Signer signer = nul 1 ; 
try { 
signer = new Signer(args) ; 
if (signer. implementation. equalsC'WSE") ) { 
signer. signWSE( ) ; 
return; 
} 

if (signer. implementation. equalsC'WSTK" ) ) { 
signer. signWSTK( ) ; 
return; 
} 

signer. si gnWSEC ) ; 
signer. signWSTK( ) ; 
} 

catch (Exception e) { 
System. out. printlnt "\nl_'un des parametres est incorrect ou absent, 
return; 
) 



} 



private void signWSEO { 
// Installation du client en fonction du descripteur correspondant. 
String deploymentDi rectory = new StringtWSTKConstants .WSTKJOME 

+"/services/demos/wss -signature/deployment" ) ; 
String cl ientWSDDFile = deploymentDi rectory+"/deploy_cl ient_WSE.wsdd" 
try { 

WSTKService.processWSDDFile(cl ientWSDDFile); 
} 
catch (Exception e) { 

Sys tern. out. println(e) ; 



System. out .printlnC'Signature et invocation du service Web .NET..."); 
Float value - null ; 

try { 

// Creation d'une instance du service local. 

Service service = new ServiceO; 

Call call = (Call) service. createCal 1 () ; 

String accessPoint = 

"http: //local host:80/WSS-Signature/StockQuotationService.asmx" ; 
call .setTargetEndpointAddress(new URL(accessPoint) ) ; 
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cal 1 . addParametertnew QName("urn:WSS-Signature" , "symbol " ) , 
new QNamet "http://www.w3.org/2001/XMLSchema" , "string"), 
String. class, ParameterMode. IN) ; 

cal 1 .setReturnType(new QName( 

"http://www.w3.org/Z001/XMLSchema", "float"), float. class) ; 

cal 1 . setllseSOAPAction(true) ; 

call .setSOAPActionURI("urn:WSS-Signature/GetQuote"); 

cal 1 . setOperationName(new QName( "urn:WSS-Signature" , "GetQuote") ) ; 

// Invocation du service Web .NET. 

System. out. println("\nInvocation de : " + accessPoint) ; 

value = (Float)cal 1 .invoke( new 0bject[] {symbol}); 

// Affichage du resultat de 1 'invocation. 

System. out. printlnC'Valeur de 1 'action " + symbol + " : " + value); 
} 
catch (Exception e) { 

Sys tern. out. println(e) ; 
} 

// Desinstallation du client en fonction du descripteur correspondant . 
deploymentDi rectory = new String(WSTKConstants .WSTKJOME 

+" /services /demos /wss -signature/deployment") ; 
cl ientWSDDFile = deploymentDi rectory+"/undeploy_cl ient_WSE.wsdd" ; 
try { 

WSTKService.processWSDDFiletcl ientWSDDFile); 
} 
catch (Exception e) { 

Sys tern. out. println(e) ; 



private void signWSTKO { 

// Installation du client en fonction du descripteur correspondant. 
String deploymentDi rectory = new String(WSTKConstants. WSTKJOME 

+"/ services /demos /wss -signature/deployment") ; 
String cl ientWSDDFile = deploymentDi rectory+"/deploy_cl ient_WSTK.wsdd" 
try { 

WSTKService.processWSDDFiletcl ientWSDDFile); 
} 
catch (Exception e) { 

Sys tern. out. println(e) ; 
} 

System. out. println( "Signature et invocation du service Web Java..."); 
Float val ue = nul 1 ; 

try { 

// Creation d'une instance du service local. 

Service service = new ServiceO; 

Call call = (Call) service. createCal 1 () ; 
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String accessPoint = "http://local host:8080/wstk/wss-signature/services/ 

*»SignatureStockQuoteService" ; 

cal 1 .setTargetEndpointAddress(new URL (access Point) ) ; 

cal 1 .addParameter(new QNameC", "inO"), 

new QName( "http://www.w3.org/2001/XMLSchema" , "string"), 

String. class, ParameterMode. IN) ; 
cal 1 .setReturnType(new QName( 

"http://www.w3.org/2001/XMLSchema", "float"), float. class); 
cal 1 .setUseSOAPAction(true) ; 
call .setSOAPActionURK""); 

cal 1 .setOperationName(new QName( "http: //local host :8080/wstk/wss -signature/services/ 
^•SignatureStockQuoteService" , "getQuote" ) ) ; 

// Invocation du service Web .NET. 

System. out. printlnt "\nInvocation de ; " + accessPoint); 

value = (Float)cal 1 .invoke( new 0bject[] {symbol}); 

// Affichage du resultat de 1 'invocation. 

System, out. printlnt "Valeur de Taction " + symbol + " : " + value); 
} 
catch (Exception e) { 

System. out. println(e) ; 
} 

// Desinstal lation du client en fonction du descripteur correspondant. 
deploymentDi rectory - new String(WSTKConstants.WSTK_HOME 

+"/services/demos/wss -signature/deployment" ) ; 
cl ientWSDDFile = deploymentDi rectory+"/undeploy_cl ient_WSTK.wsdd" ; 
try { 

WSTKServi ce . processWSDDFi 1 e( cl i entWSDDFi 1 e) ; 
} 
catch (Exception e) { 

System. out. println(e) ; 



} 

) 

La classe Signer.java necessite un parametre (minimum) ou deux parametres a F execution : 

• Le premier parametre (obligatoire) correspond au code de la valeur boursiere (chaine de carac- 
teres) dont on veut obtenir la cote : IBM ou MSFT, par exemple. 

• Le deuxieme parametre (facultatif) precise le service Web a invoquer : WSE signifie que le client 
doit s'adresser au serveur .NET, WSTK coiTespond au serveur Java et toute autre valeur (ou 
aucune valeur) provoque Finvocation successive des deux serveurs. 

Les descripteurs WSDD d' installation et de desinstallation Axis, utilises par la classe Signer.java, 
sont au nombre de six : 

• descripteur deployed ient_WSE.wsdd : le descripteur d'installation des handlers Axis cote client a 
destination du serveur .NET ; 
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• descripteur depl oy_cl 1 ent_WSTK.wsdd : le descripteur d' installation des handlers Axis cote client a 
destination du serveur Java ; 

• descripteur deploy_server.wsdd : le descripteur d'installation des handlers Axis et du serveur 
Java ; 

• descripteur undeploy_client_WSE.wsdd : le descripteur de desinstallation des handlers Axis cote 
client vers le serveur .NET ; 

• descripteur undeploy_client_WSTK.wsdd : le descripteur de desinstallation des handlers Axis du 
cote client vers le serveur Java ; 

• descripteur undeploy_server.wsdd : le descripteur de desinstallation des handlers Axis et du 
serveur Java. 

Les descripteurs de deploiement utilisent deux handlers d'origine IBM qui sont charges de signer les 
messages SOAP en partance (vers le client ou le serveur) et de traiter les messages SOAP signes en 
reception (du client ou du serveur). La description des handlers reference un fichier de configuration 
au format XML qui permet de specifier le comportement des handlers selon les besoins des echanges. 
Les deux fichiers de configuration sont localises dans le meme repertoire que celui des descripteurs 
de deploiement (depl oyment). 

Le fichier de configuration wssecuri ty-cl i ent . xml est parametre de la maniere suivante : 

<?xml version="1.0"?> 
<clientbinding> 
<service-ref> 
<port-qname-binding> 
<C1 i entServi ceConf i g> 
<RequestSenderServiceConfig> 
<SigningParts> 
<Reference part="body"/> 
<Reference part="timestamp"/> 
</SigningParts> 

<AddCreatedTimestamp flag="true" expi res="PlM"/> 
</RequestSenderServiceConfig> 
<ResponseReceiverServiceConfig> 
<Requi redSignedParts> 
<Reference part="body"/> 
<Reference part="timestamp"/> 
</Requi redSignedParts> 
</ResponseRecei verServiceConfig> 
</Cl i entServi ceConfig> 
<C1 ientBindingConfig> 
<RequestSenderBindingConfig> 
<SigningKey> 
<KeyStore type="jks" 
path="C:/wstk-3.3/services/demos/wss-signature/common/keystore.db" 
storepass="wstkwse"/> 
<PrivateKey alias="user" keypass="wstkwse"/> 
</SigningKey> 
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</RequestSenderBindingConfig> 
<ResponseRecei verBindingConfig> 
<TrustAnchorList> 

<TrustAnyCertificate/> 
</TrustAnchorList> 
</ResponseRecei verBindingConfig> 
</Cl ientBindingConfig> 
</port-qname-binding> 
</service-ref> 
</cl ientbinding> 

Ce fichier permet done d'exprimer des directives au handler charge de la signature des messages 
SOAP. Malheureusement, la documentation du WSTK est muette sur les possibilites de parametrage 
offertes. Intuitivement, on peut voir qu'un timestamp doit etre ajoute a l'en-tete de securite et que 
celui-ci ainsi que le corps du message SOAP doivent etre signes. Le certificat a utiliser pour signer les 
messages est stocke dans un entrepot identifie par Felement KeyStore. 

Le fichier de configuration wssecurity-server.xml se presente ainsi : 

<?xml version="1.0" encoding="UTF-8"?> 
<wsbinding> 
<ws-desc-binding> 
<pc-binding> 
<ServerServiceConfig> 
<RequestReceiverServiceConfig> 
<RequiredSignedParts> 
<Reference part="body"/> 
<Reference part="timestamp"/> 
</RequiredSignedParts> 
</RequestRecei verServiceConfig> 
</ServerServiceConfig> 
<ServerBindingConfig> 
<RequestReceiverBindingConfig> 
<TrustAnchorList> 

<TrustAnyCertificate/> 
</TrustAnchorList> 
</RequestRecei verBindingConfig> 
<ResponseSenderBindingConfig/> 
</ServerBindingConfig> 
</pc-binding> 
</ws-desc-binding> 
</wsbinding> 

Ici, le parametrage s'adresse au handler en charge de la reception des messages SOAP signes. Celui- 
ci doit s'assurer que Felement timestamp et le corps du message sont signes. 

Pour bien comprendre le fonctionnement du sous-systeme de gestion des flux de Axis, et notamment 
les concepts de handler et de chaine de handlers, le lecteur pourra se reporter a la section intitulee 
« Message Flow Subsystem » du guide d' architecture (voir http://ws.apache.org/axis). 
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Implementations WS-Security utilisees par les handlers Axis 

Le moteur d'execution Axis d' Apache (voir http://ws.apache.org/axis) presente egalement un exemple de signature 
de message SOAP, via I'utilisation de handlers cote client et cote serveur. Cet exemple fait appel a rimplementation 
d'XML Signature realisee par la communaute Apache par rintermediaire du projet XML Security (voir http:// 
xml.apache.org/security). Ce projet integre deja XML Signature et travaille a rimplementation d'XML Encryption. 
Puis ce sera le tour d'XKMS. 

En ce qui concerne I'usage de Axis par le WSTK d'IBM, rimplementation WS Security utilisee est celle d'IBM 
alphaWorks : XML Security Suite (voir http://www.alphaworks.ibm.com/tech/xmlsecuritysuite). Cette implementation 
prend en charge XML Signature et XML Encryption et prevoit I'integration d'XACML. 



Le descripteur deploy_cl ient_WSE.wsdd definit ainsi le deploiement des handlers cote client vers le 
serveur .NET : 

deployment xmlns="http://xml .apache.org/axis/wsdd/" 
xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 
<handler name="log" type=" Java: org. apache. axis.handlers.LogHandler"/> 
<handler name="wssecurity-cl i en t- sender" 
type=" Java: com. ibm.wstk.axis.handlers.SecuritySender"> 
<parameter name="configPath" 

val ue="services/demos/wss-signature/deployment/wssecurity-client.xml "/> 
<parameter name="printBefore" val ue="false"/> 
<parameter name="printAfter" val ue="fal se"/> 
<parameter name="logLevel " value=""/> 
</handler> 

<handler name="wssecurity-cl ient- receiver" 
type=" Java: com. ibm.wstk.axis.handlers.SecurityReceiver"> 
<parameter name="configPath" 

val ue="services/demos/wss-signature/deployment/wssecurity-client.xml "/> 
<parameter name="printBefore" val ue="false"/> 
<parameter name="printAfter" val ue="fal se"/> 
<parameter name="logLevel " value=""/> 
</handler> 

<service name="urn:WSS-Signature"> 
<requestFlow> 
<handler type="log"/> 

<handler type="wssecurity-cl ient- sender "/> 
</requestFlow> 
<responseFlow> 
<handler type="log"/> 

<! --handler type="wssecurity-c1 ient-receiver"/--> 
</responseFlow> 
</service> 
</deployment> 

Ici, le service nomme urn:WSS-Signature utilise trois handlers : le handler log est utilise avant les 
handlers wssecuri ty- client- sender ou ws security- cl ient -receiver (ce dernier n' est pas utilise dans 
cet exemple), ce qui permet de visualiser le message SOAP, au moment du traitement par le handler. 
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Le handler wssecurity -client -sender reference laclasse com. ibm.wstk. axis, handlers. Security Sen- 
der d'origine IBM, chargee de signer les messages SOAP qui se presentent via le flux entrant du 
handler, en fonction des directives exprimees dans le fichier de configuration configPath. 

Le descripteur deploy_cl1ent_WSTK.wsdd definit le deploiement des handlers cote client vers le 
serveur Java de la maniere suivante : 

deployment xmlns="http://xml .apache.org/axis/wsdd/" 
xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 
<handler name="log" type=" Java: org. apache. axis. handlers. LogHandler"/> 
<handler name="wssecurity-cl ient- sender" 
type=" Java: com. ibm.wstk.axis.handlers.SecuritySender"> 
<parameter name="configPath" 

val ue=" services /demos /wss -si gnat ure/deployment/wssecurity-cl ient.xml "/> 
<parameter name="printBefore" value="false"/> 
<parameter name="printAfter" val ue="false"/> 
<parameter name="logl_evel " value=""/> 
</handler> 

<handler name="ws security-client- receiver" 
type=" Java: com. ibm.wstk. axis. handlers. Security Receiver") 
<parameter name="configPath" 

val ue=" services /demos /wss -si gnat ure/deployment/wssecurity-cl ient.xml "/> 
<parameter name="printBefore" value="false"/> 
<parameter name="printAfter" val ue="false"/> 
<parameter name="logLevel " value=""/> 
</handler> 
<service name= 
"http: //local host:8080/wstk/wss-signature/services/SignatureStockQuoteService"> 
<requestFlow> 
<handler type="log"/> 

<handler ty pe="ws security-client- sender "/> 
</requestFlow> 
<responseFlow> 
<handler type="log"/> 

<! --handler type="wssecurity-cl ient-receiver"/--> 
</responseFlow> 
</service> 
</deployment> 

Le descripteur depl oy^server . wsdd definit le deploiement des handlers Axis cote serveur Java : 

deployment xmlns="http://xml .apache.org/axis/wsdd/" 
xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 
<handler name="log" type=" Java: org. apache. axis. handlers. LogHandler"/> 
<handler name="ws security-server- receiver" 

type=" Java: com. ibm.wstk.axis.handlers.SecurityReceiver"> 

<parameter name="configPath" 
val ue=" services /demos /wss -signature/deployment/wssecurity-server.xml "/> 

<parameter name="printBefore" value="false"/> 

<parameter name="printAfter" val ue="false"/> 

<parameter name="logLevel " value=""/> 
</handler> 
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<handler name="ws security- server- sender" 
type=" Java: com. ibm.wstk.axis.handlers.SecuritySender"> 
<parameter name="configPath" 

val ue="services/demos/wss-signature/deployment/wssecurity-server.xml "/> 
<parameter name="printBefore" val ue="false"/> 
<parameter name="printAfter" val ue="fal se"/> 
<parameter name="logLevel " value=""/> 
</handler> 

<service name="SignatureStockQuoteService" provider="java:RPC"> 
<requestFlow> 
<handler type="log"/> 

<handler type="ws security- server- receiver "/> 
</requestFlow> 
<responseFlow> 
<handler type="log"/> 

<handler type="ws security- server- sender "/> 
</responseFlow> 

<parameter name="className" value="StockQuotationService"/> 
<parameter name="allowedMethods" val ue="getQuote"/> 
</service> 
</deployment> 

Le descripteur undeploy_client_WSE.wsdd definit la desinstallation des handlers cote client vers le 
serveur .NET : 

<undeployment xmlns="http://xml .apache.org/axis/wsdd/" 

xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 

<handler name="wssecurity-sender"/> 

<service name="urn:WSS-Signature"/> 
</undeployment> 

Le descripteur undeploy_client_WSTK.wsdd definit la desinstallation des handlers cote client vers le 
serveur Java : 

<undeployment xmlns="http://xml .apache.org/axis/wsdd/" 

xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 

<handler name="wssecurity-sender"/> 

<service name="http:// local host:8080/wstk/wss-signature-cl ient /services/ 

*SignatureStockQuoteService"/> 
</undeployment> 

Le descripteur undepl oy_server.wsdd definit la desinstallation des handlers et du serveur Java : 

<undeployment xmlns="http://xml .apache.org/axis/wsdd/" 

xmlns: java="http://xml .apache.org/axis/wsdd/providers/java"> 

<handler name="wssecurity- server- receiver "/> 

<service name="SignatureStockQuoteService"/> 
</undeployment> 
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Au final, le repertoire wss-signature, avant deploiement dans le serveur Tomcat, se presente tel que 
l'illustre la figure 19-11 : 
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Comme pour le client .NET, le client Java doit disposer, via le handler de signature des messages 
SOAP, d'un certificat X509 accessible a partir d'un entrepot de cles Java (JKS ou Java Key Store). 
Pour cela, on peut creer un fichier de commande createKeyStore.bat dans le repertoire common. 

Ce fichier active Foutil key tool du SDK J2SE arm de creer cet entrepot et un certificat adequat (il faut 
veiller a la coherence entre les parametres de la commande keytool et les parametres enregistres dans 
l'element KeyStore du fichier de configuration wssecurity-client.xml). Le fichier de commande 
createKeyStore.bat se presente ainsi : 

@echo off 

set _JAVA_HOME=%JAVA_HOME% 

set JAVA_HOME=C:/Jdkl.3.1-02 

%JAVA_HOME%/bin/keytool -genkey -keystore keystore.db -storepass wstkwse 
-keyalg rsa -dname "CN=nom. prenom@domaine.fr" -alias user -keypass wstkwse 

set JAVA_HOME=%_JAVA_HOME« 
set _JAVA_H0ME= 

pause 

Le deploiement de l'exemple Java dans le serveur Tomcat est realise a l'aide de la commande wstk- 
conf i g . bat situee dans le repertoire C : \wstk-3 . 3\bi n du WSTK. Cela a pour effet d'afficher un ecran 
de configuration des services Web. Dans l'onglet Configure Services de cet ecran, il faut cocher la 
case qui correspond au nouveau projet demos\wss-signature en maintenant les autres parametres 
jusqu'a la fin de la configuration, ce qui provoque la generation d'un fichier wstk. jar qui est ensuite 
copie dans le repertoire C : \Tomcat_4 . . 6\webapps de Tomcat. Puis il faut demarrer le serveur Tomcat, 
ce qui declenche le deploiement automatique de F application. 
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II reste a deployer le serveur Java. Cela est realise par la commande suivante : 

deploy deploy_server.wsdd 
La commande depl oy, situee dans le repertoire depl oyment, est ainsi codee : 

©echo off 

setlocal 

if exist "%WSTK_HOME%\bi n\wstkenv.bat" goto wstkenvok 
echo WSTKJOME enviroment is not set correctly 
goto done 

:wstkenvok 

call "SWSTK_HOMEX\bin\wstkenv" 

Java -classpath %K1K_CP%: "C:\Tomcat_4. 0. 6\webapps\wstk\WEB- INF\1 ib\axis. jar" 

*»org. apache. axis.cl ient.AdminClient %* -1 http://localhost:8080/wstk/services/AdminService 

:done 

Une derniere manipulation est necessaire. La commande wstkconfig.bat « oublie » de deployer les 
fichiers log. jar et ibmjceprovider. jar necessaires au fonctionnement du service Web Java dans le 
repertoire C:\Tomcat_4. 0.6\webapps\wstk\WEB-INF\l ib de Tomcat. II faut done les copier manuelle- 
ment a partir du repertoire C : \wstk-3 . 3\1 1 b du WSTK, puis arreter et redemarrer Tomcat pour prendre 
en compte ces changements. 

Fonctionnement de I'exemple 

Lorsque les applications sont deployees et parametrees comme indique precedemment, nous pouvons 
proceder a F execution des differentes variantes de I'exemple. 

Linvocation du service Web .NET a partir du client .NET s'effectue par la commande suivante : 

Signer MSFT nom.prenom@domaine.fr WSE 
Cela provoque Faffichage des informations suivantes : 

Signature et invocation du service Web .NET... 

Objet du certificat choisi : CN=nom. prenom@domaine.fr, E= nom.prenom@domaine.fr, 

OID. 2. 5. 4. 5=39767443 

Identificateur de la cle : 9QqAs/j/Hl uET7yVAGvqDBP5vTE= 

Cle publique : 30818902818100DD8E680D5C5DE8FCA99DBE9AE2EF9E1D83F39 

E70C313F2F1AD1F431367DA988DE9BFB0DCAV841753258D24FACC556582C9DE8B17A100FCA23B3F2 

E4E8C6732EB437FA5A95F5D3A503E732B4DF3E2735A01A9ENJ14354662B4490F20B705AC55AD9B63 

D3A433996E9703E421771EF8E1C0D25F4B16F921F2DSDE38054E65ADB350203010001 

Invocation de : http://local host:80/WSS-Signature/StockQuotationService.asmx 
Valeur de 1 'action MSFT : 55,25 

De meme, l'invocation du service Web Java a partir du client .NET s'effectue ainsi : 

Signer MSFT nom.prenom@domaine.fr WSTK 
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Les invocations successives des services Web .NET et Java a partir du client .NET sont obtenues par 
la commande : 

Signer MSFT nom.prenom@domaine.fr 

De la meme maniere, il est possible d'utiliser le client .NET a partir de l'application WSS-Si gnature- 
Cl i ent dans Visual Studio NET Pour cela, il suffit de modifier les proprietes du projet (cliquer avec 
le bouton droit de la souris sur le projet WSS-Si gnature-Cli ent dans la fenetre de l'explorateur de 
solution, puis selectionner les proprietes de configuration et debogage), et d'ajouter les parametres 
que nous venons de voir aux arguments de la ligne de commande. 

De maniere symetrique, l'invocation du service Web .NET a partir du client Java s'effectue, par 
exemple, par la commande suivante : 

Java -classpath £CLASSPATH% WSSSignature. Signer IBM WSE 

Cela provoque l'affichage des informations suivantes : 

Signature et invocation du service Web .NET... 

Invocation de : http://local host:80/WSS-Signature/StockQuotationService.asmx 
Valeur de 1 'action IBM : 55.25 

De meme, l'invocation du service Web Java a partir du client Java s'effectue ainsi : 

Java -classpath %CLASSPATH% WSSSignature. Signer IBM WSTK 

ou l'invocation successive des services Web .NET et Java a partir du client Java par la commande : 

Java -classpath £CLASSPATH% WSSSignature. Signer IBM 



Exemple d'un message SOAP signe 

Le message ci-apres correspond a une requete du client Java vers le service Web .NET : 

<?xml version="1.0" encoding="UTF-8"?> 
<soapenv:Envelope 
xmlns :soapenv=" http://schemas.xml soap.org/soap/envelope/" 
xmlns :xsd=" http://www.w3.org/2001/XMLSchema" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header> 
<wsse:Security 
soapenv:mustUnderstand="l" 

xmlns :wsse=" http://schemas.xml soap.org/ws/2002/07/secext"> 
<wsse:BinarySecurityToken 

EncodingType="wsse:Base64Binary" ValueType="wsse:X509v3" 

wsu:Id="wssecurity_binary_security_token_id_998331122190779727_1050175599789" 
xmlns:wsu=" http://schemas.xml soap.org/ws/2002/07/utility"> 
MIICfjCCAecCBD6WzDAwDQYJKoZIhvcNAQEEBQAwgYUxCzAJBgNVBAYTAkZSMRYwFAYDVQQIEwlJbGUtZGUtRn 
JhbmNlMQ4wDAYDVQQHEwVQYXJpczEYMBYGAlUEChMPbW9uT3JnYW5pc2F0aW9uMREwDwYDVQQLEwhtb25Vbml0ZTEhM 
B8GAlUEAxMYbm9tLnByZW5vbUBtb25kb21haW51LmZyMB4XDTAzMDQxMTE0MDc0NFoXDTAzMDcxMDE0MDc0NFowgYUx 
CzAJBgNVBAYTAkZSMRYwFAYDVQQIEwlJbGUtZGUtRnJhbmNlMQ4wDAYDVQQHEwVQYXJpczEYMBYGAlUEChMPbW9uT3J 
nYW5pc2F0aW9uMRECFwYDVQQLEwhtb25Vbml0ZTEhMB8GAlUEAxMYbm9tLnByZW5vbUBtb25kb21haW51LmZyMIGfMA 
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0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoezJ6r0XG+09zI0G+sD0gQGVEd0SM3DImeDXncHTmodLa0IcAAskclKtcX 
PnTYS0E0cS96d3zLuu6+hzo3z/uAvvg+YtrCr6KcoazrFlQ7m56BT0V8PGoeHCoDyuoEfvkZTYpdu8e/clvm/ 
oB0LL2dxxa0+L69kxiel6JuQLsQwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAFjF/MrfvWRJlT70CT4qVwfVc43gciH/ 
s6SgXPlitow3WqK9v06nwWLeXshvbwz4L3xP01K/dihEqIkv0AqJj3Wi5G765PuFlPnKM2nalfYLNnRWW0yoqRhga 
XGSB29PGFuxmHYJt/15hh/iIc61wsfKP0cajjrLoKDPK4fC4fVf 
</wsse:BinarySecurityToken> 

<Signature xmlns=" http://www.w3.Org/2000/09/xmldsig#"> 
<SignedInfo> 
<Canonical izationMethod Algorithm^ 

"http://www.w3.org/2001/10/xml -exc-cl4n#"/> 
<SignatureMethod Algorithm^ 

"http://www.w3.Org/2000/09/xmldsig#rsa-shalV> 
<Reference URI = 

"#wssecurity_body_id_8804114875168701414_1050175599658"> 
<Transforms> 
<Transform Algorithm^ 

"http://www.w3.org/2001/10/xml -exc-cl4n#"/> 
</Transforms> 
<DigestMethod Algorithm= 

"http://www.w3.org/2000/09/xmldsig#shal"/> 
<DigestValue> 

c7B8UgU0jmLRiMNZC754Kxd00I = 
</DigestValue> 
</Reference> 

<Reference URI="#tsc_5408438582690354645_1050175599638"> 
<Transforms> 
<Transform Algorithm= 

"http://www.w3.org/2001/10/xml -exc-cl4n#"/> 
</Transforms> 
<DigestMethod Algorithm= 

"http://www.w3.org/2000/09/xmldsig#shal"/> 
<DigestValue> 

6t3IKny91rddHBVRcTzORL5vleM= 
</DigestValue> 
</Reference> 

<Reference URI="#tse_6860873448026709957_1050175599638"> 
<Transforms> 
<Transform Algorithm= 

"http://www.w3.org/2001/10/xml -exc-cl4n#"/> 
</Transforms> 
<DigestMethod Algorithm= 

" http://www.w3.Org/2000/09/xmldsig#shalV> 
<DigestValue> 

2d20RMZsgsBH9WYMfkEQ6szz9ZU= 
</DigestValue> 
</Reference> 
</SignedInfo> 
<SignatureVal ue> 
llXR3Y6rWXbAUflCJtu7vVlnft6ZLM00xZGpHoglkTn+o66LH91qad+VPJkj59fvU4uzoN+mpGZ+pbsj7UAIF8ZF0h 
ASkkd+/mciSbSDm00YwGErkbFTG5bCGTQD/FbfwNcmBNDRltK3IifWHLedGd+dP3jV4gbkZqvK4zmXlko= 
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</SignatureValue> 
<KeyInfo> 
<wsse:SecurityTokenReference> 
<wsse: Reference URI="#wssecurity_binary_security_token_id_998331 122 1907 
*-79727_1050175599789'7> 
</wsse:SecurityTokenReference> 
</KeyInfo> 
</Signature> 
</wsse:Security> 
<wsu:Timestamp 
xmlns:wsu=" http://schemas.xml soap.org/ws/2002/07/util ity"> 
<wsu:Created wsu: Id="tsc_5408438582690354645_1050175599638"> 

2003-04-12T19:26:39Z 
</wsu:Created> 
<wsu: Expires wsu: Id="tse_6860873448026709957_1050175599638"> 

2003-05-12T19:26:39Z 
</wsu:Expires> 
</wsu:Timestamp> 
</soapenv:Header> 
<soapenv:Body 
wsu:Id="wssecurity_body_id_8804114875168701414_1050175599658" 
xmlns:wsu=" http://schemas.xml soap.org/ws/2002/07/utility"> 
<nsl:GetQuote soapenv:encodingStyle= 

"http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:nsl="urn:WSS-Signature"> 

<nsl: symbol xsi : ty pe="xsd:string">MSFT</nsl: symbol > 
</nsl:GetQuote> 
</soapenv:Body> 
</soapenv:Envelope> 

Dans ce message SOAP, la section WS-Security correspond a l'element wsse: Security. Le destina- 
taire du message doit imperativement (attribut soapenv:mustUnderstand="l") traiter cette entree d'en- 
tete de securite. Cet element de securite est associe a un jeton de securite de type certificat X509v3 
encode en binaire base 64 (element wsse:BinarySecurityToken), reference par l'element Keylnfo. 
L'element Signed Info decrit le contenu signe du message. L'algorithme utilise pour signer le message 
repose sur une combinaison des algorithmes RSA et SHA1 (element SignatureMethod). La signature 
comporte trois condenses (digests) correspondant a la signature de trois elements du message SOAP : 
les elements soapenv:Body, wsu: Created et wsu: Expires. Ces trois elements correspondent a ceux qui 
sont signes par defaut par 1' implementation Web Services Enhancements de Microsoft : ce parame- 
trage de WSE peut etre modifie par 1' intermediate de la propriete SignatureOptions de la classe 
Signature. L'element wsu:Timestamp est ajoute au message SOAP, comme le recommande la specifi- 
cation WS-Security, afin d'eviter une attaque par interception et reinjection du message (replay 
attack). 

Cet exemple illustre le surcout en bande passante que genere l'utilisation de la signature numerique. 
Dans le cas present, la faille de la requete HTTP est multipliee par un facteur proche de six. 
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Conclusion 

Des technologies de securite disponibles depuis plusieurs annees permettent la prise en charge de la 
securite point a point, au niveau transport, entre applications reparties sur Internet. 

Les implementations de F infrastructure de securite des services Web disponibles aujourd'hui 
(compatibles WS-Security 1.0) permettent la prise en charge de la confidentialite et de l'integrite des 
messages ainsi que Fauthentification des interlocuteurs, avec un niveau satisfaisant d'interoperabilite 
entre J2EE et .NET. 

Des architectures orientees services plus sophistiquees et dynamiques demandent des fonctions de 
1' infrastructure de securite qui sont encore partiellement ou imparfaitement definies et implementees. 
Le processus de specification et de normalisation en cours semble pouvoir garantir que la roadmap 
definie en avril 2002 sera respectee : des trois sujets d' infrastructure (fiabilite des echanges, gestion 
de la securite, gestion des transactions), la gestion de la securite est certainement le sujet le mieux loti 
en termes de consensus sur les objectifs et d'effort de specification et d' implementation. 

La gestion de la securite dans les architectures orientees services sur Internet genere des besoins 
accrus en ce qui concerne 1' architecture materielle. II est facile de constater que 1' application des 
signatures et du chiffrement a comme resultat une augmentation importante de la taille des messages, 
qui dans certains cas peut se mesurer en un ordre de grandeur, voire plus. La demande en bande 
passante va augmenter en consequence. 

Ces memes procedures sont gourmandes en puissance de calcul : la prise en charge de la securite va 
transformer des applications de gestion, traditionnellement peu consommatrices de temps machine 
pur, en applications ayant des besoins importants pour l'execution des fonctions de hachage, des 
procedures de signature et de validation, des procedures de chiffrement et dechiffrement, ainsi que 
des procedures accessories de canonisation et de codage. 

Une des reponses a la demande accrue de puissance du processeur est Futilisation plus rationnelle de 
la puissance disponible et done la mise en ceuvre d' architectures de grilles d'ordinateurs, d'autant 
plus pertinentes que certaines taches de traitement d'un message (comme la validation de plusieurs 
signatures independantes) peuvent etre executees en parallele. 
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La gestion des transactions 



Nous avons defini la prestation de services comme 1' ensemble des resultats des traitements effectues 
par une application (qui joue le role de prestataire) exploitables par une ou plusieurs applications (qui 
jouent le role de clients). 

Les resultats d'une prestation peuvent appartenir a trois categories : 

• Les informations collectees, generees ou calculees par 1' application prestataire : F application pres- 
tataire met ces informations a disposition de 1' application cliente. Cette categorie comporte des 
prestations aussi disparates que le calcul mathematique intensif ou la recherche etendue sur des 
bases d' informations reparties. 

• Les transitions d'etat de l'application prestataire et des ressources qu'elle gere : ces transitions 
sont effectuees en couplage avec des traitements de controle et de calcul executes par l'application 
prestataire. La prestation reside dans l'execution de ces traitements qui qualifient et accomplissent 
les transitions d'etat, ainsi que dans la gestion des etats eux-memes et de leurs proprietes comme 
la persistance. L'application prestataire gere les transitions d'etat pour le compte de l'application 
cliente. Ainsi, un systeme de reservation aerienne effectue la reservation d'une place d' avion et 
gere la permanence de cette reservation. 

• Les actions sur I ' environnement effectuees par l'application prestataire pour le compte de l'appli- 
cation cliente : ces actions sont generalement declenchees en tant qu'effets de bord de traitements 
de controle et de calcul, qui les qualifient et les preparent, en couplage avec des transitions d'etat. 
Les interactions entre applications, c'est-a-dire les emissions/receptions de messages, appartien- 
nent a cette categorie aussi bien que le pilotage de dispositifs peripheriques pour obtenir, par 
exemple, l'impression d'un bordereau. L'application prestataire gere l'accomplissement de ces 
actions pour le compte de l'application cliente. 

Generalement, la prestation de services est organisee en unites de prestation, resultats de tdches iden- 
tifies et dotees d'un cycle de vie. Une unite de prestation peut comprendre des resultats issus des 
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trois categories confondues. Par exemple, la reservation/achat du billet d' avion peut comporter une 
transition d'etat avec permanence de l'etat final (une place est reservee et le reste jusqu'a nouvel 
ordre), un effet de bord (un billet est imprime) et la restitution d' informations (le numero de la place). 

La gestion d'etat 

Les taches qui produisent les unites de prestation presentent en realite trois niveaux de gestion d'etat, 
qui correspondent directement aux trois categories listees ci-avant : 

• Les prestations sans etat : la tache correspondante ne produit aucune transition d'etat. Rentrent 
dans cette categorie les exemples cites de calcul intensif et de recherche sur des bases d'informa- 
tions reparties et, en general, tout traitement dont le seul resultat est la restitution d'informations. 
La meme occuiTence de tache peut etre executee plusieurs fois de suite sans effets autres que des 
effets temporaires comme l'occupation et, eventuellement, le verrouillage de ressources de calcul, 
de memoire et d' information. Lors de la repetition de la tache, les informations livrees comme 
resultat de l'execution peuvent rester invariantes, ce qui arrive lorsque Ton demande l'execution 
d'un calcul avec les memes donnees et les memes parametres. Les resultats de la tache peuvent 
aussi varier au cours des repetitions, car si la tache est sans etat, l'application, elle, peut gerer des 
etats qui evoluent (par exemple, la base de donnees de reservation des places d' avion) et F interro- 
gation est d'ailleurs effectuee pour obtenir l'etat le plus « frais ». 

• Les prestations avec gestion d'etat interne : la tache correspondante produit des transitions d'etat 
directement gerees par les applications prestataires. En regie generate, l'accomplissement, plus 
d'une fois, d'une occurrence de la tache produit des transitions d'etat successives : l'etat final n'est 
pas le meme que celui qui est produit lorsque la tache n'est executee qu'une seule fois (par 
exemple, lorsque Ton passe deux fois une ecriture comptable qui correspond au retrait d'une 
somme d' argent d'un compte). Lorsque l'execution repetee de la tache produit le meme resultat 
que la premiere fois, on dit que la tache est idempotente : l'execution repetee de la tache ramene 
toujours au meme etat, qui est un point fixe. Un exemple de tache idempotente est la suppression 
d'un fichier identifie de facon unique dans le temps et dans l'espace et dont l'identifiant n'est pas 
reutilisable : une deuxieme tentative de suppression produit un message d'erreur et ne change pas 
l'etat du systeme. Le propre de la tache avec gestion d'etat interne (qu'elle soit idempotente ou 
non) est qu'elle peut toujours, independamment de la complexite des traitements requis et si Ton 
a pris les precautions necessaires, etre defaite, c'est-a-dire que Ton peut toujours revenir a l'etat 
precedent. Cela implique en general de defaire non seulement F occuiTence de la tache en question, 
mais aussi toutes celles qui ont suivi et qui ont provoque des transitions d'etat depuis. 

• Les prestations avec gestion d'etat de V environnement : la tache correspondante produit des actions 
qui changent l'etat de F environnement, en coherence avec une transition d'etat interne. Les presta- 
tions utilisent parfois les effets de bord pour changer l'etat de Fenvironnement. Lors de l'impression 
d'un billet avec reservation, le document produit n'est pas seulement un support d' information, il 
constitue egalement un titre qui donne certains droits et obligations a son possesseur. Par ailleurs, le 
changement de l'etat de Fenvironnement est independant de Faction physique d'impression du billet 
(le « billet electronique », de plus en plus repandu, en est la preuve s'il en faut) : dans ce cas, le chan- 
gement de l'etat interne du systeme represente directement le changement d'etat de Fenvironnement. 
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Le propre de l'etat de l'environnement, du point de vue de l'application prestataire, est que, contrai- 
rement aux etats internes, il est irreversible. Les etats de l'environnement ne peuvent pas etre defaits 
par l'application prestataire, mais ils peuvent parfois etre compenses, ce qui signifie que l'application 
peut prendre des dispositions qui amenent le systeme global (les applications et l'environnement) a 
un etat que Ton peut considerer proche de l'etat auquel on veut revenir (les deux etats ne sont jamais 
identiques). Par exemple, il est possible d'effectuer successivement a la reservation d'une place, 
l'annulation de cette reservation : on passe a un etat dans lequel, comme dans l'etat initial, cette place 
etait libre et le voyageur sans reservation. La similitude s'arrete la : dans le laps de temps ecoule entre 
la reservation et l'annulation, l'avion s'est rempli, et certains voyageurs, qui veulent etre certains de 
pouvoir voler, ne se sont pas mis en liste d'attente et se sont tournes vers une compagnie concurrente. 

Les processus metier 

Les unites de prestation peuvent etre independantes, sans relation directe avec d'autres unites de 
prestation pourvues par la meme application prestataire ou par d'autres. Elles sont aussi susceptibles 
de presenter des relations de dependance logique et temporelle avec d'autres unites de prestation, 
relations organisees par ce que Ton appelle un processus metier (business process). 

Un processus metier est le contexte et le moyen dans lequel on pratique l'agregation de services : la 
prestation de services globale est la combinaison des prestations de services des applications partici- 
pant au processus. 

Un processus metier organise plusieurs applications qui executent chacune une ou plusieurs taches et 
peut etre decrit et analyse a l'aide de trois concepts cles : le concept de cooperation, le concept de 
coordination et le concept de communication. 

Pour que les unites de prestation, effectuees au cours du deroulement du processus metier, participent a 
la mise en ceuvre d'une prestation de services globale, coherente et exploitable par le client final, il faut 
qu'une forme de cooperation dans l'execution des taches soit mise en place entre les applications parti- 
cipant au processus. Les cibles des resultats de certaines taches peuvent ne pas etre l'application « client 
final », cible de la prestation globale, mais d'autres applications qui utilisent ces resultats comme 
« matieres premieres » pour fournir leur propre prestation. Les applications impliquees dans un proces- 
sus metier mettent done en ceuvre unprotocole de cooperation, qui permet d'inscrire les taches qu' elles 
executent dans un reseau de dependance logique et temporelle en vue d'un objectif global. 

Generalement, pour obtenir une cooperation efficace des applications participant a un processus 
metier, il faut mettre en ceuvre une forme de coordination. Cette coordination peut etre statiquement 
definie, a savoir etre le resultat de l'execution du scenario predetermine qui ordonne l'execution des 
taches, ou bien dynamique, e'est-a-dire obtenue via des consignes donnees a la volee par un ou 
plusieurs agents logiciels ou par des acteurs humains, qui jouent des roles de coordinateurs du 
processus ou de certaines de ses parties, a l'aide de protocoles de coordination. L'execution d'un 
scenario predetermine n'exclue pas la presence d'un ou plusieurs coordinateurs qui synchronisent 
l'execution de taches et donnent le tempo. 

Dans les architectures faiblement couplees, les applications participant a un processus metier sont 
autonomes : les protocoles de cooperation et de coordination ne peuvent pas etre executes par la prise 
de controle directe des applications participantes, mais sont toujours mis en ceuvre exclusivement par 
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l'echange d'actes de communication entre ces applications autonomes et par 1' acceptation de la part 
de ces applications de la semantique et de la pragmatique de ces actes. 

La cooperation et la coordination des taches d'un processus metier demandent imperativement la 
mise en place d'une forme de communication par echange de messages entre les applications parti- 
cipant au processus. Dans le cadre de la technologie de services Web, la cooperation et la coordi- 
nation d' applications reparties sont mises en ceuvre exclusivement via des protocoles de communi- 
cation. Les applications reparties cooperent et se coordonnent en s'envoyant des messages, definis 
dans le cadre d' interfaces WSDL, sur un protocole de messagerie propre aux services Web (SOAP, 
HTTP/POST, etc.). 

Un protocole de communication fixe la syntaxe, la semantique et la pragmatique d'un ensemble de 
messages echanges entre agents logiciels. Dans le cadre des technologies de services Web, il s'agit 
de fixer : 

• un ensemble A' interactions unitaires organisees dans des interfaces, consignees dans un document 
WSDL; 

• des protocoles de conversation, c'est-a-dire un echange « contractuel » d' interactions unitaires qui 
peut etre represente comme une machine a etats finis, et done comme une correspondance (etat, 
interaction) a etat ; 

• un ensemble de regies de definition de la semantique et de la pragmatique des interactions echangees 
dans le protocole. 

Un exemple de processus metier, qui fait l'objet d'une etude de cas approfondie dans les chapitres 22, 
23, 24, 25 et 26, est celui de l'organisation d'un voyage. La prestation globale de services resultat du 
processus est un ensemble coherent d'unites de prestations comme la reservation de la place d' avion, 
la reservation de la chambre d'hotel, la reservation de la voiture de location, etc. Ces unites de pres- 
tation sont les resultats de taches executees par des applications reparties, qui mettent en place un 
protocole de cooperation, pour eviter, par exemple, que la chambre d'hotel ne soit reservee dans une 
localite differente de celle de la destination du voyage, ou que la voiture ne soit louee a partir du jour 
qui precede la date de d'arrivee. Le protocole de cooperation n'est rien d'autre que l'echange des 
messages applicatifs entre les applications qui permet que F execution des taches s'inscrive dans la 
poursuite d'un but coherent. 

Ces taches doivent etre egalement coordonnees a differents niveaux, pour eviter que la location de la 
chambre ne se fasse meme lorsqu'il n'y a plus de place dans l'avion, ou lorsque l'application de 
reservation de places est en panne. Les protocoles de coordination de ces taches se materialisent par 
l'echange de messages « generiques » de coordination a plusieurs niveaux. La construction d'un 
voyage pertinent (qui repond au besoin exprime), coherent (dans lequel les differentes prestations 
forment un tout harmonieux) et effectif (qui correspond a la realite de l'environnement) depend des 
capacites des applications participantes mais aussi de la qualite des protocoles de cooperation et de 
coordination mis en ceuvre. 

L'infrastructure de gestion de transactions 

Une infrastructure de gestion de transactions fournit un service technique qui permet de gerer certaines 
proprietes operationnelles des processus metier et des prestations qu'ils produisent. 



La gestion des transactions 

Chapitre 20 

Ces proprietes sont propres a la qualite de service des prestations individuelles et de la prestation 
globale et touchent essentiellement deux domaines : 

• la resistance aux defaillances, qui doit etre entendue comme la capacite des applications partici- 
pantes a neutraliser, ou au moins a reduire, les consequences de leurs defaillances temporaires 
aussi bien sur les prestations unitaires qu'elles pourvoient que sur la prestation globale ; 

• la gestion de la concurrence, qui doit etre entendue comme la capacite, de la pail des applications 
participantes, de fournir des prestations de services pour plusieurs clients en meme temps avec une 
gestion correcte des conflits d' allocation de ressources. 

Les proprietes operationnelles qui qualifient un processus metier comme une transaction sont genera- 
lement designees par l'acronyme ACID (pour atomicite, coherence, isolation et durabilite). 

La propriete d' atomicite du processus assure que la prestation globale qu'il produit est assuree 
entierement ou pas du tout, meme en presence de defaillances temporaires des applications 
prestataires. Les etats intermediaires obtenus par l'execution de la transaction sont transitoires et ne 
sont pas accessibles de l'exterieur de la transaction. 

La propriete d'isolation du processus assure que la prestation globale qu'il produit est pourvue 
comme si elle etait la seule prestation en cours de production, meme en situation de concurrence avec 
d'autres prestations produites en meme temps par les applications participantes. La propriete d'isola- 
tion assure aussi, reciproquement, que les etats intermediaires et finaux produits dans le deroulement 
de la transaction ne sont pas visibles avant un acte explicite de confirmation de la transaction. 

La durabilite est la propriete du processus qui assure que les etats produits par l'execution du proces- 
sus sont durables, ne peuvent etre changes que par d'autres processus autorises et sont capables de 
survivre aux defaillances temporaires des applications prestataires et de leurs supports de persistance. 

La coherence est la propriete du processus qui assure que son execution fait evoluer les applications 
participantes et l'environnement d'etats fonctionnellement corrects et coherents entre eux a d'autres 
etats tout autant fonctionnellement corrects et coherents. Cette propriete est assuree avant tout par un 
modele fonctionnel (les regies de gestion metier et le protocole de cooperation) correct et bien imple- 
ments. L infrastructure de gestion des transactions garantit, dans une certaine mesure, que les etats 
des applications participantes restent coherents meme en presence de defaillances et de concurrence 
dans la production des prestations. 

Les infrastructures de gestion de transactions assurent normalement les proprietes d' atomicite, isola- 
tion et durabilite pour les prestations sans etat ou avec gestion d'etat interne. Ces proprietes ne 
peuvent etre totalement garanties pour les transactions qui comprennent des effets de bord a cause du 
caractere irreversible de ces derniers et de la difficulte a gerer les defaillances des dispositifs qui 
accomplissent physiquement ces effets. Des techniques automatisees peuvent etre employees, au 
moins pour detecter les defaillances des dispositifs qui executent les actions, mais l'intervention 
d'acteurs humains dans les situations de defaillance ne peut pas etre exclue a priori. 

Une transaction est un processus metier qui produit des transitions d'etat qui ne deviennent durables 
et accessibles aux autres applications qu'apres achevement et, ensuite, confirmation du processus : 
avant l'etape de confirmation du processus, les transitions d'etat sont confinees dans un espace de 
travail prive et ne sont pas effectives. Une transaction est done soit executee correctement jusqu'au 
bout, soit arretee, pour diverses raisons, par exemple la defaillance d'une des applications participantes. 
Dans le premier cas, la transaction est dite achevee et les changements d'etat peuvent devenir 
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effectifs, publics et durables si la transaction est confirmee. Dans le deuxieme cas, la transaction est 
arretee en echec. 

Une transaction arretee en echec est annulee d'office : c'est comme si elle n'avait jamais eu lieu. En 
revanche, une transaction achevee peut etre soit confirmee, et l'etat qu'elle a produit devient effectif, 
durable et accessible, soit annulee, et dans ce cas aussi, tout se passe comme si elle n'avait jamais eu 
lieu. 

La confirmation d'une transaction est un acte volontaire, qui normalement est du ressort de F applica- 
tion qui pilote le protocole de cooperation de la prestation globale produite par la transaction, et qui 
demande la mise en ceuvre d'un protocole de coordination entre les applications participantes pour 
arriver a la confirmation ou a Fannulation de la transaction. 

Un des protocoles de coordination les plus utilises est le protocole de confirmation en deux etapes. 
Ce protocole distingue, apres achevement de la transaction, une premiere etape de preparation et une 
deuxieme etape de confirmation (ou annulation) proprement dite. Pour etre mis en ceuvre, ce proto- 
cole necessite qu'un agent logiciel, qui peut etre l'une des applications participantes ou un agent 
specialise, joue le role de coordinateur. Au cours de la premiere etape, le coordinateur demande aux 
applications participantes de se preparer a la confirmation de la transaction. Chaque application parti- 
cipante repond au coordinateur qu'elle a acheve sa tache avec succes, ou bien que sa tache est arretee 
en echec. Si toutes les applications participantes ont acheve avec succes leurs taches, le coordinateur 
leur demande de confirmer les changements d'etat produits et la transaction est confirmee. Si une 
seule des taches est arretee en echec, le coordinateur demande a toutes les applications participantes 
d'annuler les transitions d'etat produites par leurs taches et la transaction est annulee. 

Les limites de la gestion transactionnelle 

La gestion des transactions est un outil important pour la mise en ceuvre de processus metier, mais il 
ne peut etre utilise qu'avec parcimonie. L'execution de transactions implique un fonctionnement 
synchrone et un couplage fort entre les applications participant au processus. 

La permanence et la durabilite des etats des applications sont garanties par des ressources persistan- 
tes. La gestion des transactions implique que, pendant la duree de la transaction, les ressources qui 
gerent les etats sont verrouillees et ne sont pas accessibles en dehors de la transaction en cours. Cela 
pose deux problemes majeurs, qui sont par ailleurs imbriques : 

• un probleme de viabilite de l'approche des transactions, pour les processus metier longs ; 

• un probleme de confiance reciproque entre les applications et les agents logiciels impliques. 

La viabilite 

La gestion des transactions est interessante surtout parce qu'elle elimine le probleme de la gestion au 
niveau applicatif des conditions d'erreur et de defaillance, techniques et eventuellement applicatives. 
Les problemes de gestion de la coherence des etats applicatifs, suite a des defaillances techniques 
des applications participantes, sont resolus par 1' annulation pure et simple de la transaction et par 
l'execution d'une nouvelle tentative. Cette methode radicale de resolution des problemes est parfois 
employee dans certains systemes lors de F echec des regies applicatives, meme si la solution d'un 
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probleme applicatif par annulation technique de la transaction n'est pas vraiment appropriee. Par 
exemple, il faut eviter de traiter la situation de manque de place dans l'avion par une annulation 
technique de la transaction de reservation : la solution correcte est une transaction confirmee qui 
restitue r information de manque de place. 

La gestion des transactions simplifie done le developpement des applications, mais elle n'est pas 
directement applicable a des processus metier longs. Un processus metier long est un processus 
informatique qui accompagne un scenario fonctionnel se deroulant dans Fenvironnement sur une 
longue periode (par exemple : un cycle de vente, de la commande a la facturation, en passant par une 
livraison qui prend plusieurs jours). Dans ce cas, le verrouillage long de ressources critiques n'est 
tout simplement pas viable. En outre, l'expertise metier, confronted a des situations d'erreur ou de 
defaillance dans les activites humaines, permet parfois de trouver des parades plus astucieuses que le 
retour en arriere suite a l'annulation et la repetition mecanique du processus a partir du debut. 

La confiance 

Dans une transaction, la fiabilite et la performance du processus global sont inferieures a la fiabilite 
et la performance de la moins fiable et moins performante des applications participantes ! La periode 
de verrouillage des ressources pour 1' application la plus performante est dictee par la rapidite 
d' execution de la moins performante ! Une application qui produit des echecs a repetition, et done de 
nouveaux essais, penalise les autres applications de niveau de fiabilite superieur. L'etat durable 
produit par la transaction est la combinaison coherente et indissociable des etats geres par les appli- 
cations participantes : si l'une des applications perd entierement son etat par une panne catastrophi- 
que de son systeme de persistance, l'etat global est perdu, et sa reconstruction « manuelle » penible. 

Le probleme de la confiance se pose egalement au sujet des agents logiciels qui jouent le role (deli- 
cat) de coordinateurs de transactions (nous verrons par la suite qu'il y a plusieurs niveaux de coordi- 
nation et que les roles peuvent etre specialises). Concretement, la zone de faiblesse du protocole de 
confirmation en deux etapes est justement la deuxieme etape : entre la preparation de la confirmation 
et la confirmation ou l'annulation de la transaction, les applications participantes sont dans un etat 
d' incertitude quant a Tissue de la transaction. Une panne franche longue du coordinateur dans la 
deuxieme etape laisse les applications participantes dans une situation bloquee, dans laquelle les 
ressources restent verrouillees (et le deverrouillage de la situation demande une intervention 
manuelle d'un administrateur). Une panne franche d'une application participante dans la deuxieme 
etape necessite, apres redemarrage, la resynchronisation avec le coordinateur pour connaitre Tissue 
de la transaction. Le coordinateur doit etre mis en ceuvre par un agent logiciel sophistique et extre- 
mement fiable. 

En conclusion, pour mettre en ceuvre des transactions entre applications reparties controlees par des 
acteurs professionnels differents, il faut qu'une confiance importante sur les niveaux de qualite de 
service soit etablie entre les participants. Attention, le terme « confiance » utilise dans cette section 
denote un concept different de celui qui est propre au domaine de la gestion de la securite (chapitre 
19). La confiance sur la qualite de service ne peut etre engendree que par deux moyens : 

• des accords prives, a savoir une relation de partenariat entre les organisations parties prenantes 
du processus et une connaissance reciproque preexistante, couplees a des engagements sur les 
niveaux de qualite de service des agents logiciels et des applications ; 
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• des engagements publics certifies, c'est-a-dire une publication des engagements de qualite de 
service dans les offres de contrats des services applicatifs et des services techniques de coordina- 
tion, et un suivi de la tenue de ces engagements contractuels par des autorites de certification inde- 
pendantes. 

La deuxieme approche, plus generate, semble inevitable pour mettre en ceuvre des transactions 
dont l'ensemble des participants et des coordinateurs est forme dynamiquement, dans un reseau de 
services Web sur Internet. C'est le cas de l'agence de voyages qui choisit dynamiquement ses 
partenaires pour 1' organisation du voyage et, une fois les partenaires choisis, entre dans un processus 
metier transactionnel avec eux. 

Pour atteindre ce niveau dans la technologie des services Web, il reste encore beaucoup de travail a 
accomplir car, a ce jour, aucun effort public de specification de langage de description d'engagements 
de qualite de service Web n'a ete entrepris. 



Les activites 

La cooperation entre plusieurs applications dans un processus metier peut egalement se derouler dans 
un cadre different de celui de la gestion des transactions. Nous nommerons de maniere convention- 
nelle un processus metier qui possede certaines proprietes differentes, voire opposees aux proprietes 
des transactions, une activite. Les activites son aussi appelees dans la litterature transactions longues, 
parfois par opposition aux transactions atomiques, qui sont les transactions decrites dans la section 
precedente. 

La premiere difference entre une activite et une transaction est que les etats des applications dans le 
deroulement de 1' activite sont generalement accessibles, alors que les etats des applications au cours 
de l'execution d'une transaction sont prives, transitoires et non accessibles : seuls les etats finaux 
deviennent effectifs, durables et accessibles et cela seulement apres confirmation de la transaction. 

Le propre d'un processus metier concu comme une activite est qu'il peut etre recursivement decom- 
pose en taches. Un outil fondamental pour decrire une activite est done Yarbre de decomposition de 
V activite en taches, dont un exemple est illustre figure 20-9. 

Le deroulement d'une activite est coordonne par un ou plusieurs coordinateurs. En effet, il est possi- 
ble de definir un contexte de coordination et un coordinateur pour chaque nceud intermediate de 
l'arbre des taches. Le contexte de coordination est dit subordonne a celui de la tache mere et le coor- 
dinateur est appele coordinateur interpose (entre le coordinateur de la tache mere et les taches filles). 

Une tache active, apres demarrage, peut etre achevee, arretee, close ou supprimee (la signification 
exacte de ces etats sera precisee par la suite). Elle peut egalement etre compensee par une tache compen- 
satoire qui a pour but d'effectuer un traitement dont le resultat s'apparente a ce qu'en comptabilite on 
appelle une contre-passation. 

Les mondes des transactions et des activites ne sont pas separes, au contraire : des groupes de taches 
feuilles de l'arbre de decomposition peuvent etre executes dans un cadre transactionnel. Si cette 
approche est appliquee systematiquement, le deroulement de 1' activite passe par une succession 
d'etats coherents, persistants, accessibles, obtenue par une suite dynamique de transactions. 
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Les proprietes des activites sont synthetisees en termes de differences avec les proprietes des transac- 
tions dans le tableau comparatif qui suit. 



Transactions et activites : Tableau comparatif 



Transactions Activites 


line transaction est atomique, isolee et durable. La succes- 
sion d'etats produits durant le deroulement de la transaction 
n'est pas signifiante, les etats sont transitoires et ne sont pas 
accessibles de I'exterieur de la transaction. Ce qui compte 
est I'etat initial (auquel on revient par annulation) ou I'etat final 
(apres confirmation). Ces deux etats seulement sont effectifs, 
durables et accessibles de I'exterieur. 


Une activite evolue par etats intermediaires effectifs, dura- 
bles et accessibles. Les etats intermediaires et leur histori- 
que dans le deroulement de I'activite sont visibles de 
I'exterieur de I'activite et peuvent etre tres signifiants du 
point de vue metier. Par exemple, la perte de I'historique 
d'un processus de vente complexe peut etre tres domma- 
geable pour la relation client. 


Les transactions ont une structure plate : en ce qui concerne 
la confirmation/annulation, les taches qui la composent sont 
toutes au meme niveau, dans le sens qu'elles sont toutes 
confirmees ou sont toutes annulees. Une tache composante 
ne peut etre executee comme une tache independante vis-a- 
vis du protocole de confirmation et, a fortiori, ne peut etre 
decomposee en transactions independantes. 


Les activites ont la structure imbriquee et recursive d'un 
arbre de decomposition des taches. Une tache peut etre 
dynamiquement composee de plusieurs sous-taches, avec 
des contextes de coordination et des coordinateurs propres, 
et ainsi de suite. Les feuilles de I'arbre de decomposition des 
taches gagnent a etre executees dans un cadre transaction- 
nel, car dans ce cas le deroulement de I'activite est un 
enchainement de transitions coherentes et atomiques 
d'etats durables et accessibles. La flexibility de I'activite est 
amelioree par la disponibilite de taches et, eventuellement, 
de transactions compensators. 


La partie finale du cycle de vie (preparation, confirmation ou 
annulation) d'une transaction est coordonnee par un coor- 
donnateur unique. Le contexte de coordination d'une tran- 
saction est unique et sa portee est identique a celle de la 
transaction. 


La partie finale du cycle de vie d'une tache (terminaison, 
compensation, suppression) est coordonnee par un coordi- 
nateur. Le cycle de vie d'une sous-tache peut etre coordonne 
par un coordinateur interpose, different du coordinateur de la 
tache mere, et ainsi de suite. 


La levee d'une d'exception au cours de I'execution d'une 
tache de la transaction, non recuperable par la tache elle- 
meme, conduit inevitablement a I'echec et a I'annulation de la 
transaction. 


La levee d'une exception lors de I'execution d'une sous-tache 
peut etre prise en compte par la tache mere, laquelle peut 
passer le controle a une autre tache prevue a cet effet. 


La liste des participants a une transaction est figee jusqu'a la 
confirmation ou I'annulation de la transaction. 


La liste des participants a une activite est dynamique. Les 
participants peuvent quitter I'activite a n'importe quel 
moment. 


Une transaction est typiquement composee d'un ensemble 
de traitements qui ont peu d'interactions avec I'environnement 
exterieur. 


Une activite est typiquement un processus informatique 
reparti qui peut avoir beaucoup d'interactions avec I'environ- 
nement car il accompagne un scenario fonctionnel qui se 
deroule dans I'environnement. 


Une transaction est typiquement de courte duree, surtout 
pour eviter le verrouillage long de ressources critiques. 


Une activite est typiquement de longue duree, car liee a des 
scenarios fonctionnels de longue duree. 


La consommation de ressources informatiques de la part 
d'une transaction reste limitee. 


La consommation de ressources informatiques de la part 
d'une activite peut devenir tres importante. Par exemple, 
une activite peut mettre en oeuvre un nombre important de 
transactions. 
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Les technologies de services Web appliquees aux transactions 
et activites 

Une technologie d' infrastructure de services Web comme la gestion de transactions et d' activites se 
presente comme un ensemble de protocoles de communication entre agents logiciels. Les agents qui 
jouent un role specifique dans le fonctionnement de F infrastructure, tels les coordinateurs, sont definis 
comme des services tiers. 

La specification d'un protocole de cooperation ou de coordination en tant que protocole de commu- 
nication definit des exigences et des contraintes sur 1' implementation des agents qui interviennent 
dans l'execution du protocole, mais elle ne constitue en aucun cas une specification organique ou de 
conception de ces agents. Un ensemble d' agents implemented sur des architectures et technologies 
logicielles heterogenes, voire incompatibles, qui mettent en ceuvre les interfaces, les protocoles de 
conversation et les regies de semantique et pragmatique dictes par la specification, forment ensemble 
un moteur reparti de gestion de transactions et d' activites. 

Nous allons presenter deux technologies de services Web pour la gestion de transactions : 

• Business Transaction Protocol (BTP). 

• Lensemble forme par WS-Coordination et WS-Transaction. 

BTP est une technologie plus ancienne, qui a donne lieu a des implementations dont certaines 
aujourd'hui ne sont plus disponibles. WS-Coordination et WS-Transaction, couplees avec le langage 
de description executable des processus metier BPEL (Business Process Execution Language) est 
une technologie soutenue par IBM, Microsoft et BEA, ce dernier etant a Forigine de BTP. Par ailleurs 
WS-Coordination et WS-Transaction reprennent Fapproche BTP en la simplifiant. Lajout du 
langage de scripting au processus metier BPEL permet egalement d'utiliser les technologies WS- 
Coordination et WS-Transaction a partir d'un niveau d' abstraction superieure. 

Nous allons decrire brievement BTP dans la section qui suit. Les specifications WS-Cooordination et 
WS-Transaction sont presentees en detail dans le reste du chapitre. BPEL, avec d'autres langages de 
scripting de processus metier, fait l'objet du chapitre 21, « Gestion des processus metier ». 

Business Transaction Protocol 

BTP (Business Transaction Protocol) est une specification developpee dans le cadre d'un comite 
technique OASIS (Organization for the Advancement of Structured Information Standards, voir http:/ 
/oasis-open. org). La premiere reunion du comite technique BTP a eu lieu le 13 mars 2001 et la specifi- 
cation BTP 1.0 a ete approuvee par le comite le 16 mai 2002. BEA a ete l'un des promoteurs de 
l'initiative (https://www.oasis-open.org/committees/business-transactions), a laquelle ont participe Hewlett- 
Packard et Oracle, mais dans laquelle on note l'absence remarquee dTBM et de Microsoft. 

BTP est un protocole de communication qui permet de gerer des transactions et des activites executees 
par des applications reparties sur Internet. 

La specification est done composee de : 

• la definition d'un ensemble d' interactions unitaires organisees en interfaces entre les participants 
techniques et applicatifs a la mise en ceuvre d'une transaction repartie ; 
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• la definition d'un ensemble de roles pour les participants et notamment de roles de coordination ; 

• la definition de protocoles de conversation entre les coordinateurs et les applications participant a 
la transaction ; 

• la definition de la semantique et de la pragmatiques des messages echanges. 
La specification definit la liaison avec SOAP 1 . 1 et HTTP 1.1. 

Les objectifs affiches de BTP sont : 

• la definition d'un modele de gestion de transactions pour des applications reparties sur Internet ; 

• la coordination et la composition d'issues et de resultats fiables de taches reparties en presence 
d'une infrastructure d'echange potentiellement non fiable ; 

• la gestion du cycle de vie des transactions ; 

• la prise en charge de transactions entre applications faiblement couplees qui communiquent entre 
elles de facon asynchrone ; 

• la prise en charge de transactions « longues » ; 

• la coordination d' interactions entre participants multiples ; 

• la constitution d'un socle trans actionnel pour la mise en ceuvre de processus metier. 
BTP distingue deux types de transactions : 

• les transactions atomiques, ou atonies BTP, dont la definition est proche de celle de transaction 
proposee dans la premiere section de ce chapitre ; 

• les transactions « metier » ou cohesions BTP, dont la definition est proche de celle d'activite. 

Les atomes BTP 

Le modele des transactions atomiques ou atomes BTP est proche du modele des transactions dans les 
systemes fortement couples, avec la difference importante que la contrainte d' isolation est en partie 
relachee. Certains etats intermediaries ou non continues peuvent etre rendus visibles sous la respon- 
sabilite de l'application qui les gere. Du point de vue technique, on peut dire que BTP n'exige pas des 
participants aux transactions le suivi strict de la regie de verrouillage en deux phases (qui demande 
que tous les verrous soient poses avant que le premier soit leve). 

La fonction de coordination est assuree par un coordinateur, eventuellement seconde par des sous- 
coordinateurs, qui gerent chacun un ensemble d' applications participantes. 

L execution de l'atome BTP est atomique (tout ou rien) et son resultat reste durable. 

Les cohesions BTP 

Une cohesion BTP possede un ensemble de proprietes qui lui donnent une position intermediate 
entre les transactions et les activites telles que nous les avons definies. Une cohesion BTP peut etre 
organisee en une structure arborescente de sous-cohesions, similaire a l'arbre de decomposition de 
l'activite. 

Les cohesions BTP relachent les proprietes d'atomicite, d' isolation et de durabilite des transactions : 

• les resultats d'une cohesion BTP peuvent etre organises en sous-ensembles ; 
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• les etats intermediaries et non confrrmes peuvent etre visibles ; 

• une partie des resultats peut etre volatile (non durable). 

Le niveau et le point de relachement des contraintes est generalement negocie entre le coordinateur et 
les participants : de ce fait, le coordinateur d'une cohesion BTP joue un role beaucoup plus complexe 
que le coordinateur d'un atome BTP. 

BTP ne contient pas de formalisme pour definir des conversations ni pour concevoir ou orchestrer des 
processus metier, mais se pose plutot comme une technologie utilisable pour mettre en ceuvre des 
langages de scenarios de processus metier. 

Les implementations 

BTP est le premier effort de specification dans le domaine de la gestion des transactions pour les 
services Web. Cet effort s'est concretise dans plusieurs implementations. La premiere est le produit 
de Hewlett-Packard HP Web Services Transactions (HP WST). Ce produit a une valeur purement 
historique car, a cause d'un changement d' orientation de Hewlett-Packard, il n'est plus commercia- 
lise ni disponible au telechargement (depuis le 15 septembre 2002). 

Collaxa (http://www.collaxa.com), qui, avec HP, a produit une des premieres implementations BTP, est 
ensuite « passee a la concurrence » et aujourd'hui Collaxa 2.0 est la premiere implementation de 
l'ensemble BPEL/WS-Coordination/WS-Transaction. 

Autres implementations : 

• Arjuna : Web Services Transactioning (WST), voir http://www.arjuna.com/products/arjunawst/index.html ; 

• Choreology : Cohesions 1.0, voir http://www.choreology.com ; 

• Expertlog : Oasis-BTP ObjectWeb implementation with JOTM 0.3 alpha, voir http://alpha.experlog.com/ 
xml/btp ; 

• SourceForge : voir http://debian-sf.objectweb.org/projects/btp. 

Conclusion 

La specification BTP est riche mais relativement complexe. Lengagement de BEA, un initiateur de 
BTP, avec IBM et Microsoft sur les technologies de l'ensemble WS -Coordination, WS-Transaction 
et BPEL, laisse entendre que BTP doit etre considere comme une premiere experience riche d'ensei- 
gnements mais qui ne donnera pas lieu a des implementations suivies. 

WS-Coordination et WS-Transaction 

L'ensemble forme par WS-Coordination et WS-Transaction permet la mise en ceuvre de processus 
metier selon le modele des transactions et des activites. Ces specifications sont complementaires a 
une troisieme specification, BPEL (Business Process Execution Language for Web Services), qui 
definit un langage pour l'ecriture de scenarios : ces scenarios decrivent en fait le protocole de coope- 
ration applicative entre les taches d'un processus metier. Les trois specifications, dont les auteurs sont 
IBM, Microsoft et BEA, sont parues a quelques jours de distance (31 juillet 2002 et 9 aout 2002). 

La relation entre ces specifications reside dans le fait que le moteur reparti d' execution des scenarios 
mis en ceuvre par les editeurs (et avant tout par IBM, Microsoft et BEA) sur des environnements 
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d'execution heterogenes s'appuie, pour les protocoles de coordination des transactions et des activites, 
sur WS-Coordination et WS-Transaction. Une description de BPEL est presentee chapitre 21, et le 
chapitre 25 illustre Futilisation de BPEL, WS-Coordination et WS-Transaction dans une etude de cas. 



Les references aux specifications 

Web Services Coordination (WS-Coordination) - 9 August 2002 : 

- BEA : http://dev2dev.bea.com/techtrack/ws-coordination.jsp ; 
-IBM : http://www-1 06.ibm.com/deveioperworks/iibrary/ws-coor ; 

-Microsoft : http://msdn.microsoft.com/library/default.asp7urh/library/en-us/dnglobspec/html/wscoordspecindex.asp. 
Par la suite, on nommera ce document WS-Coordination. 
Web Services Transaction (WS-Transaction) - 9 August 2002 : 

- BEA : http://dev2dev.bea.com/techtrack/ws-transaction.jsp ; 

- IBM : http://www-106.ibm.com/deveioperworks/webservices/iibrary/ws-transpec/] 

-Microsoft : http://msdn.microsoft.com/library/default.asp7urh/library/en-us/dnglobspec/html/ws-transaction.asp. 
Par la suite, on nommera : 

- ce document dans son integralite WS-Transaction ; 

- la partie 1 de ce document (Atomic Transaction), WS-Transaction-AT ; 

- la partie 2 de ce document (Business Activity), WS-Transaction-BA. 



Schemas XSD et declarations WSDL 

WS-Coordination : 

- http://schemas.xmlsoap.org/ws/2002/08/wscoor/wscoor.xsd ; 

- http://schemas.xmlsoap. org/ws/2002/08/wscoor/wscoor. wsdl. 
WS-Transaction-AT : 

- http://schemas.xmlsoap.org/ws/2002/08/wstx/wstx.xsd ; 

- http://schemas.xmlsoap.org/ws/2002/08/wstx/wstx. wsdl. 
WS-Transaction-BA : 

- http://schemas.xmlsoap.org/ws/2002/08/wsba/wsba.xsd ; 

- http://schemas.xmlsoap. org/ws/2002/08/wsba/wsba. wsdl. 
Un schema avec des types et des structures d'appoint : 
http://schemas.xmlsoap.org/ws/2002/07/utility/utility.xsd. 



Les vocabulaires XML et les prefixes 

Prefixe Vocabulaire XML 

wscoor http: //schemas. xmlsoap.org/ws/2002/08/wscoor 

wstx http: //schemas .xmlsoap.org/ws/2002/08/wstx 

wsba http: //schemas. xmlsoap.org/ws/2002/08/wsba 

wsu http://schemas.xmlsoap.org/ws/2002/07/util ity 

wsdl http://schemas.xmlsoap.org/wsdl / 

xsd http://www.w3.org/2001/XMLSchema 

SOAP- EN V http://schemas.xmlsoap.org/soap/envelope/ 

ens (Prefixe pour un vocabulaire XML applicatif utilise dans les exemples) 
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BPEL 

Business Process Execution Language for Web Services, Version 1.0 - 31 July 2002 : voir http://www-106.ibm.com/ 
developerworks/webservices/library/ws-bpel. 



Larchitecture des specifications 
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Figure 20-1 

Architecture des protocoles de coordination et de cooperation. 



L' architecture generale des specifications de Fensemble WS-Coordination et WS-Transaction et de 
ses relations avec les protocoles de cooperation applicatifs est illustree figure 20-1. 

WS-Coordination est un protocole de metacoordination dans le sens qu'il permet de fixer le cadre 
generique dans lequel un protocole de coordination specifique peut se metrre en ceuvre. II est 
compose de deux sous-protocoles distincts {activation et registration), qui permettent respectivement 
de constituer un contexte de coordination pour tout protocole de coordination specifique et, pour les 
applications intervenantes, de s'enregistrer dans le contexte de coordination. 

Un contexte de coordination est utilise par un protocole de coordination specifique. WS-Transaction 
specifie deux protocoles de coordination specifiques, adaptees respectivement a la coordination des 
transactions et des activites (respectivement WS-Transaction-AT et WS-Transaction-BA). Par 
ailleurs, WS-Coordination peut etre utilise pour la mise en ceuvre d'autres protocoles de coordination 
specifiques, adaptes a d'autres utilisations. 

Les protocoles de coordination WS-Transaction sont utilises par les protocoles de cooperation appli- 
catifs. Par leur utilisation, la cooperation des applications se deroule successivement dans le cadre de 
la gestion des transactions et dans celui de la gestion des activites. 

Les protocoles de cooperation applicatifs sont specifies au moyen de langages de description des 
processus metier. Ces langages sont presentes dans le chapitre 21, « Gestion des processus metier ». 
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Parmi ces langages, BPEL est celui qui utilise directement WS -Coordination et WS-Transaction (les 
trois specifications font partie en realite d'un ensemble qui a ete defini de facon coordonnee), mais 
l'ensemble WS-Coordination/WS-Transaction pourrait etre utilise par d'autres langages. 

La securite 

Les specifications WS -Coordination et WS-Transaction recommandent « fortement » l'utilisation de 
WS-Security pour garantir rauthentification des interlocuteurs et l'integrite des messages echanges 
dans le cadre des protocoles de metacoordination (activation et registration) et de protocoles de coor- 
dination specifiques. Notamment, l'utilisation extensive de la signature est recommandee, sur l'inte- 
gralite des messages, afin d'eviter la reutilisation frauduleuse de contextes de coordination et de 
parties des messages. 

Les specifications recommandent egalement aux developpeurs d'apporter une attention particuliere 
aux dangers d'attaque en saturation (denial of service) en direction notamment des prestataires de 
services de metacoordination et des coordinateurs. 

Le chapitre 19 traite, de maniere specifique, de la gestion de la securite. 

Le style d'echange 

Tous les protocoles definis dans les specifications WS -Coordination et WS-Transaction, c'est-a-dire 
les protocoles de metacoordination (activation et registration) et les protocoles de coordination speci- 
fiques (coordination des transactions et coordination des activites), sont toujours definis au moyen 
d'un couple d' interfaces : une interface coordinateur et une interface participant. 

Au lieu de proposer une seule interface pour le prestataire du service de coordination avec des inte- 
ractions de type requete/reponse, la specification formalise systematiquement un couple d' interfaces 
avec des messages a sens unique. Les differents protocoles se chargent, pour un coordinateur et un 
participant donne, de la correlation entre la « requete » et la « reponse », en sachant que chaque 
message applicatif fait reference au contexte de coordination dans lequel il s'inscrit. 

Cette approche permet d'etendre la notion de role. Le role d'un agent logiciel est defini par l'ensem- 
ble d'interfaces coordinateur et participant qu'il implemente. On verra que dans la gestion des activi- 
tes, une application participante peut implementer une interface coordinateur et jouer le role de coor- 
dinateur pour d'autres applications. A l'inverse, un coordinateur technique peut implementer une 
interface participant d'un protocole de coordination et deleguer certaines activites de coordination a 
un autre coordinateur. L approche par role offre une grande souplesse dans la mise en ceuvre de 
1' architecture repartie. 

La fiabilite de I'echange 

La fiabilite de I'echange ne fait pas l'objet d'attention particuliere dans les specifications, sauf dans 
la specification WS-Transaction-BA, qui pose les exigences et contraintes de conception pour 
1' implementation du protocole de coordination d' activites (du cote coordinateur comme du cote 
participant) suivantes : 

• Toutes les transitions d'etat du protocole de coordination doivent etre sauvegardees, avec l'etat de 
F application et les metadonnees de coordination. 



L'infrastructure des services Web 

QUATRIEME P ARTIE 

• Tout message qui met en ceuvre une requete logique doit etre suivi par un accuse de reception. 

• L'emetteur de la requete peut renvoyer son message de requete s'il ne recoit pas le message de 
reponse apres un delai d'attente qu'il fixe lui-meme, independamment du fait qu'il ait recu 
1' accuse de reception. Le repondeur doit etre capable de reconnaitre et de traiter les doublons. 

Ces hypotheses de conception sont en fait des exigences sur la fiabilite de l'echange (transmission au 
moins une fois des messages, gestion des doublons, resistance aux pannes tranches des interlocuteurs 
par persistance des etats de l'echange). En revanche, il n'y a pas d'exigence particuliere d'echange 
fiable pour le protocole de coordination des transactions (WS-Transaction-AT), sauf la gestion des 
doublons. Sur le role de la fiabilite de l'echange dans l'architecture des specifications des services 
Web, le lecteur peut se reporter au chapitre 18. 

Les protocoles de metacoordination 

Nous avons vu que le protocole de metacoordination est compose de deux protocoles distincts : 

• le protocole d' activation ; 

• le protocole de registration. 

Le protocole d'activation sert a constituer ce que Ton appelle le contexte de coordination, qui est 
ensuite utilise par les applications pour s'y enregistrer, a l'aide du protocole de registration. 

Le protocole d'activation 

Pour fonctionner, le protocole d'activation demande F implementation de deux interfaces abstraites : 

• 1' interface coordinateur ; 

• 1' interface participant. 

Voici d'abord, la definition des messages : 

<wsdl :message name="CreateCoordinationContext"> 

<wsdl :part name="parameters" element="wscoor:CreateCoordinationContext"/> 
</wsdl :message> 
<wsdl :message name="CreateCoordinationContextResponse"> 

<wsdl:part name="parameters" 
el ement="wscoor:CreateCoordinationContext Response "/> 
</wsdl :message> 
<wsd1 :message name="Error"> 

<wsdl:part name="parameters" element="wscoor:Error"/> 
</wsdl :message> 

Linterface coordinateur 

<wsdl :portType name="ActivationCoordinatorPortType"> 

<wsdl :operation name="CreateCoordinationContext"> 
<wsdl :input message=''wscoor:CreateCoordinationContext'7> 

</wsdl :operation> 
</wsdl :portType> 
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Le type de l'element CreateCoordinationContext est le suivant : 

<xsd: complexly pe name="CreateCoordinationContextType"> 
<xsd:sequence> 
<xsd: element name="Acti vationService" type="wsu:PortReferenceType"/> 
<xsd:element ref="wsu:Expires" minOccurs="0"/> 
<xsd: element name= "Cur rentCon text" type="wscoor:CoordinationContextType" 

minOccurs="0"/> 
<xsd: element name=" Requester Reference" type="wsu:PortReferenceType"/> 
<xsd:element name="CoordinationType" type="xsd:anyURI"/> 
<xsd:any namespace="##any" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/> 
</xsd:sequence> 

<xsd: any Attribute namespace="##other" processContents="lax"/> 
</xsd:complexType> 

<xsd: element name="CreateCoordinationContext" 
type="wscoor:CreateCoordinationContextType"/> 

Le message CreateCoordinationContext est utilise pour demander a un coordinateur, prestataire du 
service d' activation, la creation et la restitution d'un contexte de coordination pour un protocole de 
coordination designe. Le coordinateur prestataire du service d' activation n'est pas forcement celui 
qui va assumer le role de coordinateur pour le protocole de coordination specifique. 

Voici le gabarit du message : 

<wscoor:CreateCoordinationContext> 
<wscoor:ActivationService> 

<wsu:Address>wst/:/4ttrfiit/t;ea l WJ</wsu:Address> 
</wscoor:Acti vationService> 
<wscoor: Requester Reference> 

<wsu : Address>wst/ : r A ttr i butedURK/visii: Mdress> 
</wscoor: Requester Reference> 

<wscoor:CoordinationType>xsd:anyt//?J</wscoor:CoordinationType> 
<wsu : Expi res>wsu:AttributedDateT1me</wsu: Expi res>? 

<wscoor: Cur rentContext>wscoor: Coordinat i onCon text Type</»scoor: Cur rentContext>? 
<!-- extensibility elements and attributes -> 

</wscoor:CreateCoordinationContext> 

Elements de la demande de creation d'un contexte de coordination 



Element Description 


ws coo r : Act i va t i on Service/wsu: Address 


Reference du port du coordinateur prestataire du service d'acti- 
vation. 


ws coo r:RequesterReference/wsu: Address 


Reference du port du participant client du service d'activation. 


wscoor:CoordinationType 


Identifiant (URI) du protocole de coordination (type de coordina- 
tion) pour lequel le contexte de coordination demande va etre 
utilise. 


wsu: Expi res 


Optionnel. La date d'expiration du contexte cree. 
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Elements de la demande de creation d'un contexte de coordination (suite) 



Element Description 


wscoor:CurrentContext 


Optionnel. Lorsqu'il n'est pas valorise, le contexte de coordination 
cree suite a la demande de creation est le contexte d'une nouvelle 
transaction ou activite (avec un nouvel identifiant). Lorsqu'il est 
valorise, le contexte cree est un contexte subordonne au contexte 
courant et fait reference a la meme transaction ou activite de ce 
contexte courant, avec un port de registration different. Par ce 
biais, il est possible de creer une hierarchie de contextes de coor- 
dination pour la meme activite ou transaction. 


L'element d'extensibilite et ses attributs. 


II est prevu d'heberger des elements d'extension qui vehiculent 
des informations specifiques voire dependantes des applications 
impliquees. 
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<wsdl :portType name="ActivationRequesterPortType"> 
<wsdl :operation name="CreateCoordinationContextResponse"> 
<wsdl : input mess age="wscoor:CreateCoordinationCon text Response "/> 
</wsdl :operation> 
<wsdl :operation name="Error"> 

<wsdl :input message="wscoor:Error"/> 
</wsdl :operation> 

</wsdl :portType> 

Void le type de l'element CreateCoordinationContextResponse : 

<xsd: complexly pe name="CreateCoordinationContextResponseType"> 
<xsd:sequence> 
<xsd: element name=" Requester Reference" type="wsu:PortReferenceType"/> 
<xsd: element name="CoordinationContext" 

type="wscoor:CoordinationContextType" minOccurs="0"/> 
<xsd:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs=" unbounded "/> 
</xsd:sequence> 

<xsd:anyAttribute namespace="##other" processContents="lax"/> 
</xsd:complexType> 
<xsd: element name="CreateCoordinationCon text Response" 

Le gabarit du message de reponse en cas de succes est le suivant : 

<wscoor:CreateCoordinationContextResponse> 
<wscoor: Requester Reference) 

<wsu : Add ress>wsu:/4 ttr i butedURK/visu : Add ress> 
</wscoor: Requester Reference) 
<wscoor:CoordinationContext> 

<wsu: Identifier>wsu:/4ttr7'iiu<:erJt//?J</wsu:Identifier> 

<wscoor:CoordinationType>xsd:anyt//?K/wscoor:CoordinationType> 

<wscoor: RegistrationService> 
<wsu:Address>wsu:/4ttr7'i)t/t;edWJ</wsu:Address> 

</wscoor:Regi strati onService> 
</wscoor:CoordinationContext> 
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<!-- extensibility elements and attributes --> 
</wscoor:CreateCoordinationContextResponse> 

Elements de la reponse a la demande de creation de contexte de coordination 



Element Description 


wscoo r : Req ues te r Ref er en ce/wsu: Address 


Reference du port du participant client du service d'activation. 


ws coo r:CoordinationCon text 


Le contexte de coordination cree par le coordinateur prestataire du ser- 
vice d'activation. II sera presente en detail dans la prochaine section. 


Lelement d'extensibilite et ses attributs. 


II est prevu d'heberger des elements d'extension qui vehiculent 
des informations specifiques voire dependantes des applications 
impliquees. 



Le type d' Error est le suivant : 

<xsd:complexType name="ErrorType"> 
<xsd:sequence> 
<xsd: element name=" Target Protocol Service" type="wsu: Port Ref erenceType"/> 
<xsd:element name="Errorcode" type="xsd:QName"/> 
<xsd:any namespace="#any" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/> 
</xsd:sequence> 
</xsd:complexType> 
<xsd:element name="Error" type="wscoor: ErrorType"/> 

Voici le gabarit de la reponse en cas d'echec (erreur wscoor) : 

<wscoor: Error> 
<wscoor: Target Protocol Service> 

<wsu:Address/> 
</wscoor: Target Protocol Service> 

<wscoor:Errorcode>wscoor: Inval idCreateParameters</wscoor: Errorcode> 
<!-- extensibility elements and attributes --> 

</wscoor: Error> 

Le code d'erreur wscoor: Inval idCreateParameters vehicule Finformation selon laquelle les argu- 
ments de la demande de creation d'un contexte de coordination sont invalides. wscoor:TargetProto- 
col Servi ce est utilise pour les retours d'erreur du service de registration. 

Le contexte de coordination 

Le contexte de coordination CoordinationContext, cree a la demande via le message CreateCoordina- 
tionContext et recupere dans le message CreateCoordinationContextResponse, est utilise ensuite par 
F application qui en fait la demande pour passer aux applications participantes les informations relatives 
a la coordination. Cet element est place comme entree de Fen-tete SOAP de messages applicatifs. 

En voici le schema : 

<xsd: element name="CoordinationContext" type=" wscoo r:CoordinationContextType"/> 
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<xsd: complexly pe name="CoordinationContextType" abstract="false"> 
<xsd : compl exContent> 
<xsd: extension base="wsu:ContextType"> 
<xsd:sequence> 
<xsd:element name="CoordinationType" type="xsd:anyURI"/> 
<xsd: element name="RegistrationService" 

type="wsu:PortReferenceType"/> 
<xsd:any namespace="#any" processContents="lax" minOccurs="0" 
maxOccurs=" unbounded "/> 
</xsd:sequence> 
</xsd:extension> 
</xsd: compl exContent> 
</xsd: compl exType> 

Le contexte de coordination contient deux informations capitales pour la mise en ceuvre concrete du 
protocole de coordination : 

• II fixe le protocole de coordination objet du contexte via F element Coordi nati onType. 

• II donne acces au coordinateur prestataire du service de registration (Regi strati onServi ce). 

Le type wscoor: Coordi nati onContextType est une extension du type wsu:ContextType. II est dote d'un 
identifiant et, eventuellement, d'une date d'expiration. La definition de ces elements est dans le 
schema « utilitaire » wsu, dont voici un extrait : 

<xsd: compl exType name="ContextType" abstract="true"> 
<xsd:sequence> 
<xsd:element ref="wsu:Expi res" minOccurs="0"/> 
<xsd:element ref="wsu: Identifier"/> 
</xsd:sequence> 

<xsd:attributeGroup ref= "wsu: common Atts"/> 
</xsd: compl exType> 

<xsd:attributeGroup name=" common Atts"> 
<xsd:attribute ref="wsu:Id" use="optional "/> 
<xsd:anyAttribute namespace="##other" processContents="lax"/> 
</xsd:attributeGroup> 

<xsd:element name="Expi res" type="wsu:AttributedDateTime"> 
<xsd:element name="Identifier" type="wsu:AttributedURI"/> 
<xsd: compl exType name="AttributedDateTime"> 
<xsd:simpleContent> 
<xsd: extension base="xsd:string"> 
<xsd:attribute name="ValueType" type="xsd:QName"/> 
<xsd:attributeGroup ref="wsu:commonAtts"/> 
</xsd:extension> 
</xsd : si mpl eContent> 
</xsd:complexType> 

<xsd: compl exType name="AttributedURI"> 
<xsd:simpleContent> 
<xsd: extension base="xsd:anyURI"> 

<xsd:attributeGroup ref="wsu:commonAtts"/> 
</xsd:extension> 
</xsd : si mpl eContent> 
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</xsd:complexType 

L'usage du contexte de coordination 

Le contexte de coordination est ensuite propage et rappele, toujours comme entree d'en-tete d'un 
message SOAP applicatif (par exemple, une requete qui entraine des traitements executes dans le 
cadre du contexte de coordination). 

Voici le gabarit d'une telle requete : 

<SOAP-ENV:Envelope> 
<SOAP-ENV:Header> 
<wscoor:CoordinationContext> 
<wsu:Expi res>wsu:AttributedDateTime</visii:Ex'pi res> 
<wsu: Identifier>wsu:^ttr7'i)utec/t//?J</wsu: Identifier) 
<wscoor:CoordinationType>xsd:a/jyt//?J</wscoor:CoordinationType> 
<wscoor:Regi strati onService> 

<wsu:Address>wsi/;/ , ort/?eferencerype</wsu:Address> 
</wscoor:Regi strati onService> 
<!-- extensibility elements and attributes --> 

</wscoor:CoordinationContext> 

</SOAP-ENV:Header> 
<SOAP-ENV:Body> 

</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Le protocole de registration 

Comme pour le protocole d' activation, le protocole de registration est mis en ceuvre a Faide de deux 
interfaces : 

• F interface coordinateur ; 

• F interface participant. 

Le protocole de registration donne la possibilite de distinguer, pour le coordinateur comme pour le 
participant, deux ports (quatre en tout) : 

• un port qui gere le protocole de registration proprement dit (prestataire du service de registration) 
et qui est fourni par le coordinateur prestataire du service d' activation ; 

• un port qui gere le protocole de coordination specifique objet de l'enregistrement (coordinateur 
specialise). 

Par ce truchement, il est done possible de distinguer, a Finterieur du coordinateur (dont 1' architecture 
d'agregation de services sera detaillee par la suite), le port en charge des registrations du port en 
charge des interactions propres au protocole specifique de coordination. De meme, une application 
qui participe au contexte de coordination pourra utiliser un port specialise pour dialoguer avec le 
coordinateur du protocole specialise different du port qu'elle a utilise pour s'enregistrer. 
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Void la definition des messages : 

<wsdl :message name="Register"> 

<wsdl:part name="parameters" element="wscoor:Register"/> 
</wsdl :message> 
<wsdl :message name="RegisterResponse") 

<wsdl :part name="parameters" element="wscoor:RegisterResponse"/> 
</wsdl :message> 
<wsdl :message name="Error"> 

<wsdl:part name="parameters" element="wscoor:Error"/> 
</wsdl :message> 

Linterface coordinateur 

<wsd1 :portType name="RegistrationCoordinatorPortType"> 

<wsdl :operation name="Register"> 
<wsdl :input message="wscoor:Register'7) 

</wsdl :operation> 
</wsdl :portType> 

Le type de Register est le suivant : 

<xsd: complexly pe name="RegisterType"> 
<xsd:sequence> 
<xsd: element name="RegistrationService" type="wsu:PortReferenceType"/> 
<xsd: element name=" Requester Reference" type="wsu:PortReferenceType"/> 
<xsd:element name="Protocol Identifier" type="xsd:anyURI"/> 
<xsd: element name=" Participant Protocol Service" 

type="wsu:PortReferenceType"/> 
<xsd:any namespace="#any" processContents="lax" minOccurs="0" 
maxOccurs=" unbounded"/) 
</xsd:sequence> 

<xsd:anyAttribute namespace="##other" processContents="lax"/> 
</xsd:complexType> 
<xsd:element name="Register" type="wscoor: RegisterType"/> 

Voici le gabarit du message : 

<wscoor:Register> 
<wscoor:Regi strati onService> 

<wsu: Add res s)wsu.-;4 fir 7 iuiedl/flK/wsu: Address) 
</wscoor:Regi strati onService> 
<wscoor: Requester Reference> 

<wsu: Add res s)wsu:/4iiT7'6u£edt/tfI</wsu: Address) 
</wscoor: Requester Reference) 

<wscoor: Protocol Identifier>xsd:anyWK/wscoor: Protocol Identifier) 
<wscoor: Participant Protocol Service) 

<wsu : Add ress>wsu:/4 ttr i butedURK/visu: Address) 
</wscoor: Participant Protocol Service) 
<!-- extensibility elements and attributes --) 

</wscoor:Register> 
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Elements de la demande d'enregistrement 



Element Description 


wscoor: Regi strati on Service 


Reference du port du coordinateur prestataire du service de regis- 
tration. 


wscoor: RequesterReference 


Reference du port du participant client du service de registration. 


wscoor: Protocol Identifier 


Identifiant du protocole bilateral de coordination aupres duquel le 
client s'enregistre. Pour la liste des identifiants des protocoles bilate- 
raux de WS-Transaction-AT et WS-Transaction-BA, voir les sections 
concernees. 


wscoor: Parti cipantProtocol Service 


Reference du port du participant a utiliser par le protocole de coordi- 
nation specifique. 


L'element d'extensibilite et ses attributs. 


II est prevu d'heberger des elements d'extension qui vehiculent des 
informations specifiques voire dependantes des applications impli- 
quees. 
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<wsdl :portType name="RegistrationRequesterPortType"> 
<wsdl :operation name="RegisterResponse"> 

<wsdl : input mess age=" wscoor: Register Response "/> 
</wsdl :operation> 
<wsdl operation name="Error"> 

<wsdl : input mess age=" wscoor: Error"/> 
</wsdl :operation> 
</wsdl :portType> 

Le typede wscoor: Regi sterResponse est le suivant : 

<xsd: complexly pe name="RegisterResponseType"> 
<xsd:sequence> 
<xsd: element name=" Requester Reference" type="wsu:PortReferenceType"/> 
<xsd: element name=" Coordinator Protocol Service" 

type="wsu:PortReferenceType"/> 
<xsd:any namespace="##any" processContents="lax" minOccurs="0" 
maxOccurs=" unbounded "/> 
</xsd:sequence> 

<xsd: any Attribute namespace="#other" processContents="lax"/> 
</xsd:complexType> 

Voici le gabarit du message wscoor: Regi sterResponse : 

<wscoor: Register Res ponse> 
<wscoor: Requester Reference> 

<wsu:Address>wsi/:/4tir7'£n/i:ed(//?I</wsu:Address> 
</wscoor: Requester Reference> 
<wscoor: Coordinator Protocol Service> 

<wsu:Address>wsu:/4ttr7'i)t/tea l (//?J</wsu:Address> 
</wscoor: Coordinator Protocol Service> 
<!-- extensibility elements and attributes --> 

</wscoor: RegisterResponse> 
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Elements de la reponse a la demande d'enregistrement 



Element Description 


wscoor: Requester Reference 


Reference du port du participant client du service de registration. 


ws coo r: Coordinator Protocol Service 


Reference du port du coordinateur a utiliser par le protocole bilateral 
de coordination specifique. 


L'element d'extensibilite et ses attributs. 


II est prevu d'heberger des elements d'extension qui vehiculent des infor- 
mations specifiques voire dependantes des applications impliquees. 



Le gabarit de la reponse en cas d'echec (eiTeur wscoor) est le suivant : 

<wscoor: Error> 
<wscoor: Target Protocol Service> 

<wsu : Add ress>wsu:/4 ttr i butedURK/visu : Add ress> 
</wscoor: Target Protocol Service> 
<wscoor:Errorcode>xsd:OWame</wscoor:Errorcode> 
<!-- extensibility elements and attributes --> 

</wscoor:Error> 

Elements du message d'erreur de registration 



Element Description 


wscoor: Tar get Protocol Service 


La reference du port du coordinateur du protocole de coordination specifique. 


wscoor:Errorcode 


Voir le tableau ci-apres. 


Les elements d'extensibilite et leurs attributs. 


II est prevu d'heberger des elements d'extension qui vehiculent des informa- 
tions specifiques voire dependantes des applications impliquees. 



Erreurs de registration 



Code d'erreur Description 


wscoor:Al ready Registered 


Le participant s'est deja enregistre pour le meme protocole de coordination sous le 
meme identifiant de contexte de coordination. 


wscoor: Inval idState 


L'etat du coordinateur prestataire du service de registration ne permet pas d'effectuer 
d'enregistrements. 


wscoor :Inval idProtocol 


Le protocole bilateral de coordination specifique n'est pas pris en charge. 


wscoor :NoActivity 


Le contexte de coordination n'existe pas. 



Le role « generique » de coordinateur 

Le role generique de coordinateur, est issu de la mise en ceuvre conjointe : 

• de F interface coordinateur d' activation (WS -Coordination) : la mise en ceuvre de ce service est 
optionnelle ; 

• de Finterface coordinateur de registration (WS -Coordination) ; 
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• d'un nombre variable d' interfaces coordinateur de protocoles de coordination specifiques (par 
exemple les protocoles de coordination des transactions et des activites definis dans WS -Trans action) ; 

• d'un nombre variable d'interfaces participant des protocoles de metacoordination et de coordination 
qui lui permettent de deleguer des activites de coordination. 

Un role de coordination minimaliste prend en charge F interface coordinateur de registration et 
l'interface coordinateur d'un protocole de coordination specifique. 

Les protocoles de coordination specifiques 

La specification WS -Trans action formalise deux protocoles de coordination : 

• Le protocole de coordination des transactions (WS-Transaction-AT) : c'est le protocole de coor- 
dination des taches dans le cadre d'une transaction. En fait, il s'agit de la formalisation du proto- 
cole multilateral de confirmation en deux etapes en technologie de services Web. 

• he, protocole de coordination des activites (WS-Transaction-BA) : il s'agit d'un protocole de coor- 
dination de taches dans le cadre d'une activite. Le protocole prevoit explicitement 1' usage d' acti- 
vites de gestion d' exceptions et de compensation. 

Ces deux protocoles peuvent etre combines : les taches feuilles, dans un arbre de decomposition 
d'une activite, peuvent etre executees dans le cadre de transactions. 



Identif iants des protocoles de coordination specifiques 

L'identifiant (URI) du protocole de coordination des transactions WS-Transaction-AT est: http://sche- 

mas .xml soap.org/ws/2002/08/wstx. 

Lidentifiant (URI) du protocole de coordination des activites WS-Transaction-BA est : http : //schemas .xml soap . org/ 

ws/2002/08/wsba. 



Le protocole de coordination des transactions 

Tous les elements qui servent a construire les messages du protocole de coordination WS-Transaction- 
AT sont de type wstx : Noti f i cati on. En voici la definition dans le schema XSD wstx : 

<xsd:complexType name=" Noti fi cati on"> 
<xsd:sequence> 
<xsd : el ement name=" Target Protocol Servi ce" type="wsu : PortRef erenceType"/> 
<xsd : el ement name="SourceProtocol Servi ce" type="wsu : PortRef erenceType"/> 
<xsd:any namespace="#other" processContents="l ax" min0ccurs="0" 
maxOccurs=" unbounded "/> 
</xsd:sequence> 

<xsd: any Attribute namespace="##other" processContents="lax"/> 
</xsd:complexType> 

L'approche utilisee par la specification est tres simple. Prenons, par exemple, le cas du message de 
confirmation (wstx: Commit). 
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Nous trouvons d'abord F element dans le schema XSD wstx : 

<xsd:element name="Commit" type="wstx:Notification"/> 
Ensuite vient le message dans la declaration WSDL wstx : 

|<wsdl :message name="Commit"> 
<wsdl:part name="parameters" element="wstx:Commit"/> 
</wsdl :message> 

Puis vient l'operation, incluse dans l'interface participant du protocole de confirmation en deux 
etapes : 

|<wsdl : operation name="Commit"> 
<wsdl :input message="wstx:Commit"/> 
</wsdl :operation> 

Le message SOAP qui vehicule dans le corps le message de coordination contient comme entree de 
l'en-tete le contexte de coordination. Voici le gabarit du message : 

<SOAP-ENV:Envelope> 
<SOAP-ENV:Header> 
<wscoor:CoordinationContext> 
<wsu: Expi res>wsu:AttributedDateTime</visu: Expi res> 
<wsu: Identifier>wst/:/4ttr7'it/tecfW7</wsu: Identifier^ 
<wscoor:CoordinationType> 

http://schemas.xmlsoip.org/ws/2002/08/wstx 
</wscoor:CoordinationType> 
<wscoor:Regi strati onService> 

<wsu:Address>wsu:Port/?eference7ypeK/wsu:Address> 
</wscoor:Regi strati onService> 
<!-- extensibility elements and attributes --> 

</wscoor:CoordinationContext> 

</SOAP-ENV:Header> 
<SOAP-ENV:Body> 
<wstx:Commit> 
<wstx:TargetProtocolService> 

wsu : PortReferenceType2 
</wstx: Target Protocol Service> 
<wstx:SourceProtocolService> 

wsu:PortReferenceType3 
</wstx:SourceProtocolService> 
</wstx:Commit> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Attention aux ports : 

• le port wsu : PortReferenceTypel est le port de registration du coordinateur ; 

• le port wsu : PortReferenceType2 est le port de coordination du participant ; 

• le port wsu : PortReferenceType3 est le port de coordination du coordinateur. 
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Les autres messages, operations et interfaces specifies dans WS-Transaction sont tous definis en 
suivant l'approche que Ton vient de presenter dans cet exemple. 

La specification WS-Transaction-AT definit en fait cinq protocoles bilateraux de coordination, 
formalises chacun par un couple d' interfaces (une pour le coordinateur et une pour le participant) et 
un protocole de conversation formalise par un graphe d'etats. On peut regretter que le protocole de 
conversation ne soit pas formalise dans un langage XML, alors que des formalismes de representation 
de protocoles de conversation ont ete proposes. 



Formalisme XML pour definir des protocoles de conversation 

Une specification simple et elegante a ete soumise par Hewlett-Packard avec la note : 

WSCL Web Services Conversation Language (WSCL) 1 .0 - W3C Note 14 March 2002 (voir http://www.w3.org/TR/ 

wscHO). 



Le protocole multilateral WS-Transaction-AT est mis en ceuvre par la combinaison de protocoles 
bilateraux entre le coordinateur et les participants au contexte de coordination. Un schema comprenant 
plusieurs protocoles bilateraux est illustre figure 20-8. 

Les cinq protocoles bilateraux sont : 

• le protocole bilateral de terminaison (Completion) ; 

• le protocole bilateral de terminaison avec acquittement (CompletionWithAck) ; 

• le protocole bilateral d'etape zero (PhaseZero) ; 

• le protocole bilateral de confirmation en deux etapes (2PC) ; 

• le protocole bilateral de notification d'issue (OutcomeNotification). 

Les identifiants des protocoles bilateraux WS-Transaction-AT, a citer comme valeur de l'element 
wscoor:Register/wscoor: Protocol Identifier, sont presentes dans le tableau suivant. 



Tableau des identifiants des protocoles bilateraux WS-Transaction-AT 


Protocole 


Identifiant 


Terminaison 


http://schemas.xmlsoap.org/ws/2002/08/wstx/Cornpletion 


Terminaison avec acquittement 


http://schemas.xml soap.org/ws/2002/08/wstx/CompletionWithAck 


Etape zero 


http://schemas.xml soap.org/ws/2002/08/wstx/PhaseZero 


Confirmation en deux etapes 


http://schemas.xmlsoap.org/ws/2002/08/wstx/2PC 


Notification d'issue 


http://schemas.xml soap.org/ws/2002/08/wstx/0utcomeNotification 



Les diagrammes d'etat que nous allons montrer dans les figures qui suivent sont simplifies, car ils 
ne comprennent ni les etats et messages d'erreur du protocole, ni les etats de defaillance de 
l'echange. 

Tous les graphes d'etats des protocoles bilateraux rentrent dans l'etat Active des l'enregistrement 
du participant aupres du coordinateur (wscoor : Regi ster) avec identifiant du protocole bilateral. 
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Le protocole bilateral de terminaison 

Le protocole bilateral de terminaison est utilise par une application (un participant) pour demander au 
coordinateur de confirmer ou annuler une transaction. 

Voici 1' interface coordinateur : 

<wsd1 :portType name="CompletionCoordinatorPortType"> 
<wsdl :operation name="Commit"> 

<wsdl :input message="wstx:Commit"/> 
</wsdl :operation> 
<wsdl : operation name="Rol lback"> 

<wsdl :input message="wstx:Rollback"/> 
</wsdl :operation> 
<wsdl :operation name="Unknown"> 

<wsdl :input message="wstx:Unknown"/> 
</wsdl :operation> 
<wsdl :operation name="Error"> 

<wsdl :input message="wstx:Error"/> 
</wsdl :operation> 
</wsdl :portType> 

Voici maintenant 1' interface participant : 

<wsdl :portType name="CompletionParticipantPortType"> 
<wsdl :operation name="Committed"> 

<wsdl :input message="wstx:Committed"/> 
</wsdl :operation> 
<wsdl :operation name="Aborted"> 

<wsdl :input message="wstx:Aborted"/> 
</wsdl :operation> 
<wsdl :operation name="Error"> 

<wsdl : input message="wstx: Error "/> 
</wsdl :operation> 
</wsdl :portType> 

Le diagramme d'etat est presente figure 20-2. 
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Figure 20-2 

Protocole bilateral de terminaison. 
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Le participant demande au coordinate™ de confirmer (Commit) ou d'annuler (Rol lback) une transac- 
tion. Le coordinateur repond avec une notification de confirmation (Committed) ou d'annulation 
(Aborted) de la transaction. La seule reponse possible a la demande d'annulation (Rollback) est la 
notification d'annulation (Aborted). Evidemment, le coordinateur peut repondre avec une notification 
d'annulation a une demande de confirmation, car, par exemple, la transaction est coordonnee par lui- 
meme a l'aide d'un protocole de confirmation en deux etapes (voir plus loin la section consacree a ce 
protocole) et une des applications participantes peut avoir notifie son arret en echec. Le coordinateur, 
apres avoir libere les ressources des participants par des demandes d'annulation, renvoie au demandeur 
une notification d'annulation (Aborted) de la transaction. 

Le protocole bilateral de terminaison avec acquittement 

Le protocole de terminaison avec acquittement est une variante du protocole de terminaison que nous 
venons de presenter (voir figure 20-3), avec ajout de l'acquittement (Notified) a la notification de 
confirmation (Committed) ou d'annulation (Aborted) de la part du participant. 
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Figure 20-3 

Protocole bilateral de terminaison avec acquittement. 

L'interface participant est identique a celle du protocole de terminaison « simple ». L'interface coor- 
dinateur est la meme, si ce n'est qu'elle comporte en plus l'interaction Noti f i ed : 

|<wsdl :operation name="Notified"> 
<wsdl :input message="wstx:Notified"/> 
</wsdl :operation> 



Le protocole bilateral de confirmation en deux etapes 

Le protocole bilateral de confirmation en deux etapes permet a un coordinateur et a une application 
d'engager une conversation dans le cadre du protocole multilateral qui permet a un ensemble 
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d' applications de confirmer ou d'annuler une transaction repartie. Le diagramme d'etat est 
presente figure 20-4. 
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Figure 20-4 

Protocole bilateral de confirmation en deux etapes. 



Voici 1' interface participant : 

<wsdl :portType name="2PCParticipantPortType"> 
<wsdl :operation name="Prepare"> 

<wsdl :input message="wstx:Prepare"/> 
</wsdl :operation> 
<wsdl :operation name="OnePhaseCommit"> 

<wsdl :input message="wstx:OnePhaseCommit"/> 
</wsdl :operation> 
<wsdl :operation name="Commit"> 

<wsdl :input message="wstx:Commit"/> 
</wsdl :operation> 
<wsdl : operation name="Rol 1 b a c k " > 

<wsdl :input message="wstx:Rollback"/> 
</wsdl :operation> 
<wsdl :operation name="Notified"> 

<wsdl :input message="wstx:Notified"/> 
</wsdl :operation> 
<wsdl :operation name="Unknown"> 

<wsdl : input message="wstx:Unknown"/> 
</wsdl :operation> 
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<wsdl :operation name="Error"> 

<wsdl :input message="wstx:Error"/> 
</wsdl :operation> 
</wsdl :portType> 

Et voici 1' interface coordinateur : 

<wsdl :portType name="2PCCoordinatorPortType"> 
<wsdl :operation name="Prepared"> 

<wsdl :input message="wstx:Prepared"/> 
</wsdl :operation> 
<wsdl :operation name="Aborted"> 

<wsdl :input message="wstx:Aborted"/> 
</wsdl :operation> 
<wsdl :operation name="ReadOnly"> 

<wsdl :input message="wstx:ReadOnly"/> 
</wsdl :operation> 
<wsdl :operation name="Committed"> 

<wsdl :input message="wstx:Committed"/> 
</wsdl :operation> 
<wsdl :operation name="Unknown"> 

<wsdl :input message="wstx:Unknown"/> 
</wsdl :operation> 
<wsdl :operation name="Repl ay"> 

<wsdl :input message="wstx:Replay"/> 
</wsdl :operation> 
<wsdl roperation name="Error"> 

<wsdl :input message="wstx:Error"/> 
</wsdl :operation> 
</wsdl :portType> 

La premiere etape 

Le coordinateur demande au participant la preparation pour la confirmation (Prepare). Par ailleurs, le 
participant peut avoir signale, de sa propre initiative, l'arret par echec de ses traitements (Aborted), ce 
qui amene le protocole a l'etat final (Ended). 

Le participant repond a la demande de preparation par : 

• la notification de fin de preparation avec succes (Prepared) : la premiere etape du protocole est 
conclue, et le coordinateur peut entamer la deuxieme etape ; 

• la notification de l'echec du traitement (Aborted), ce qui amene le protocole a l'etat final (Ended) ; 

• la notification de la defection de la deuxieme etape sans remise en cause de Tissue de la transaction 
(Readonly), car sa prestation est sans etat (le participant n'a fait que fournir des informations aux 
autres participants de la transaction). Le participant peut done quitter le contexte de coordination, 
qui continue a etre actif avec les autres participants, et liberer les ressources qu'il a verrouillees. 
Cela amene le protocole a l'etat final (Ended). 
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Le coordinateur peut egalement demander l'annulation (Rol 1 back) pure et simple de la transaction en 
cours. Par ailleurs, il peut demander une annulation impromptue (Rol 1 back) lorsque le participant est 
encore en phase de preparation (Preparing). 

En tout etat de cause, le participant repond a la demande d' annulation (Rol 1 back) par une notification 
d' annulation (Aborted), meme si la specification considere explicitement que les participants et le 
coordinateur doivent adopter un mode de fonctionnement pessimiste : le manque d' informations sur 
une transaction equivaut a son echec (une transaction qui n'est pas explicitement confirmee dans un 
delai donne est consideree comme annulee, ou, si Ton veut, une transaction est « annulee » jusqu'a sa 
confirmation). 

La deuxieme etape 

Le coordinateur, suite a la reponse Prepared, peut mettre en ceuvre la deuxieme etape du protocole, 
qui consiste a envoyer une demande de confirmation ou d' annulation a tous les participants. II peut 
envoyer des demandes de confirmation (Commit) si et seulement s'il n'a recu des participants que des 
Prepared ou des Readonly. Si un seul participant, dans le cours de la premiere etape, a notifie l'echec 
de son traitement (Aborted), il est oblige d'envoyer des demandes d'annulation (Rol 1 back) a tous les 
participants en etat Prepared. 

Les participants de la deuxieme etape sont obliges de repondre Commi tted a Commi t et Aborted a Roll - 

back. 

L'hypothese du mode de fonctionnement pessimiste conduit a un certain nombre d' optimisations 
dans F implementation du coordinateur et des participants : 

• Le coordinateur peut remettre l'inscription dans son journal des informations sur la transaction 
jusqu'a la decision de confirmation. 

• Un participant peut «oublier» la transaction apres envoi d' Aborted ou de Readonly dans la 
premiere etape. 

• Dans la deuxieme etape, apres avoir recu au moins un Aborted, le coordinateur peut oublier la tran- 
saction tout de suite apres avoir envoye les Rollback a tous les participants. II n'est pas oblige 
d'attendre les messages de reponse des participants. 

• La decision, prise au debut de la deuxieme etape, de confirmer la transaction et done d'envoyer des 
Commit aux participants en etat Prepared oblige le coordinateur a garder la trace de la transaction 
jusqu'a la collecte complete des messages Committed de la part de tous les participants de la 
deuxieme etape. 

Le protocole en une etape 

Lorsqu'il n'y a qu'un participant inscrit dans le contexte de coordination, le coordinateur peut adop- 
ter un protocole simplifie de confirmation en une etape (voir figure 20-5). Ce protocole sert pratique- 
ment a deleguer au participant la decision de confirmation et d'annulation. 

On peut remarquer que le graphe d'etats est le meme que celui du protocole de terminaison (voir 
figure 20-2), si ce n'est que les roles dans les messages sont inverses. 
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Figure 20-5 

Protocole bilateral de confirmation en une etape. 

Le protocole bilateral d'etape zero 

Le protocole bilateral d'etape zero (figure 20-6) est utilise par le coordinateur pour notifier a un parti- 
cipant que le protocole de confirmation en deux etapes va demarrer. Les participants peuvent done 
effectuer des traitements ancillaires comme des effets de bord, des sauvegardes ou l'ecriture de jour- 
naux. Ce sont evidemment des actions qui doivent etre executees quelle que soit Tissue de la transac- 
tion dans laquelle les participants interviennent. 
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Figure 20-6 

Protocole bilateral d'etape zero. 

Le coordinateur notifie que Fetape zero est ouverte (PhaseZero). Le participant repond avec une noti- 
fication d'achevement de Fetape (PhaseZeroCompleted). Si un des participants repond avec un 
message d'erreur (Error), le protocole de confirmation en deux etapes ne peut pas demarrer. 
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Le protocole bilateral de notification d'issue 

Le protocole bilateral de notification d'issue (figure 20-7) est utilise pour notifier a un participant la 
terminaison et Tissue (confirmation ou annulation) d'une transaction. 

Le coordinateur envoie Tissue d'une transaction terminee (Committed ou Aborted). Le participant 
repond avec un acquittement (Noti f i ed). Le coordinateur doit garder trace de la transaction jusqu' a la 
reception de T acquittement. 
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Figure 20-7 

Protocole bilateral de notification d'issue. 



Les relations entre les protocoles 

Dans le diagramme de sequence illustre figure 20-8, nous evoquons les relations entre le protocole de 
cooperation applicatif et les differents protocoles de coordination technique. 

Une application cliente se charge d'agreger les prestations de services de plusieurs applications pres- 
tataires. Pour ce faire, elle met en ceuvre un protocole de cooperation applicatif (0) qui comporte un 
echange de messages applicatifs entre toutes les applications (entre T application cliente et les appli- 
cations prestataires, directement entre applications prestataires). Par exemple, les participants a 
Torganisation d'un voyage (agence de voyages, compagnie aerienne, chaine hoteliere, loueur de 
voitures) s'echangent des messages applicatifs pour construire un paquet forme de reservations de 
places d' avion, de chambre d' hotel et de voiture. 

S'il n'y a pas d' exigence de qualite particuliere sur le processus metier d' organisation du voyage 
(hypothese d'ecole), le protocole de cooperation tout seul peut suffire. En revanche, pour imposer des 
qualites trans actionnelles au processus et a son resultat, deux conditions sont necessaires : 

• Les applications participates doivent etre en mesure d'executer les traitements definis dans le 
protocole de cooperation dans un cadre transactionnel. 

• II est necessaire de coordonner les activites des applications participantes par la mise en ceuvre 
d'un protocole de conversation entre elles et un prestataire de services de coordination qui joue le 
role de coordinateur attitre. 
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Figure 20-8 

Protocoles de coordination et cooperation d'une transaction. 



La premiere condition est satisfaite par F implementation de moteurs trans actionnels dans les applica- 
tions participantes. Ces moteurs doivent etre capables de garantir les proprietes transactionnelles 
(atomicite, isolation et durabilite) des traitements. 
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La coordination passe par la mise en ceuvre de trois protocoles : 

• le protocole d' activation (©) WS -Coordination ; 

• le protocole de registration (0,0) WS -Coordination ; 

• le protocole multilateral de gestion des transactions (0) WS-Transaction-AT. 

Les moteurs transactionnels des applications prestataires doivent mettre en ceuvre les interfaces parti- 
cipant, pas forcement toutes mais au moins celle du protocole de registration et celle du protocole de 
confirmation en deux etapes (seule F application cliente doit mettre en ceuvre l'interface participant 
du protocole d' activation). 

Le protocole d' activation (0) est initialise par l'application cliente (en fait, l'application qui se 
charge de l'agregation de la prestation de services) qui demande au coordinateur de creer un contexte 
de cooperation pour une nouvelle transaction (wscoor:CreateCoordinationContext), avec comme 
valeur de wscoor:CoordinationType, Fidentifiant de WS-Transaction-AT, l'URI http://sche- 
rnas.xmlsoap.org/ws/2002/08/wstx. La reponse wscoor:CreateCoordinationContextResponse vehicule 
l'identifiant du contexte de coordination qui fait office d'identifiant de la transaction. 

L'application cliente s'enregistre aupres du coordinateur (0) pour participer au protocole bilateral de 
terminaison avec acquittement (CompletionWithAck) par l'echange wscoor: Register / wscoor: Register- 
Response. Ensuite, l'application cliente se charge de mettre en ceuvre le protocole de cooperation 
applicatif, a savoir d'invoquer les prestations de services des applications prestataires. Les inter- 
actions vehiculent toujours le contexte de coordination. La premiere de ces interactions (que nous 
avons appelee conventionnellement ens: Start) declenche pour chaque application prestataire le 
protocole de registration (0). Chaque application prestataire s'enregistre aupres du coordinateur 
dans le contexte de coordination de la transaction. Toutes les applications prestataires s'enregistrent 
pour participer au protocole de confirmation en deux etapes (2PC) et certaines pour participer au 
protocole d'etape zero (PhaseZero). La reponse applicative apres enregistrement ens:StartAck fait 
partie du protocole de cooperation applicative. 

Le diagramme evoque sans les nommer les echanges du protocole de cooperation applicatif, qui pilo- 
tent un ensemble de traitements applicatifs repartis (0). Nous supposons que le protocole de coope- 
ration se deroule avec succes et qu'il se termine par l'achevement avec succes de la transaction : 
l'organisation du voyage est achevee et reussie (mais elle n'est pas encore confirmee). Pour garantir 
les proprietes transactionnelles de la prestation d' organisation du voyage, il faut derouler le protocole 
multilateral de coordination propre a la gestion transactionnelle (0). 

Ce protocole de coordination multilateral met en ceuvre entre les agents logiciels impliques dans les 
trois des protocoles bilateraux que nous avons decrits : 

• le protocole de terminaison avec acquittement ; 

• le protocole d'etape zero ; 

• le protocole de confirmation en deux etapes. 

L'application cliente, apres deroulement correct du protocole de cooperation, au moins de son point 
de vue, lance la terminaison et la confirmation de la trans action par une demande au coordinateur 
(wstx: Commit) dans le cadre du protocole bilateral de terminaison avec acquittement. 



La gestion des transactions 

Chapitre 20 

La tache du coordinateur est done d'interagir avec un certain nombre d' applications en vue d'obtenir 
la terminaison et, si possible, la confirmation de la transaction indiquee par le contexte de coordina- 
tion passe par F application cliente. II constate, a l'examen du contexte de cette transaction, qu'il y a 
des applications enregistrees pour participer au protocole de confirmation en deux etapes. Avant de 
lancer la procedure, il constate egalement qu'un certain nombre de ces applications sont egalement 
enregistrees pour participer au protocole d' etape zero. 

Le coordinateur no tine a toutes les applications enregistrees que Fetape zero est commencee 
(wstx: PhaseZero). Les applications participantes a Fetape zero renvoient toutes la notification d'acheve- 
ment avec succes de Fetape (wstx:PhaseZeroCompleted). C'est la condition necessaire pour passer au 
stade de preparation du protocole de confirmation en deux etapes. Si une seule des applications partici- 
pantes repond avec wstx: Error, le coordinateur entame la procedure d'annulation de la transaction par 
Fenvoi de wstx: Rol 1 Back a tous les participants au protocole de confirmation en deux etapes et par Fenvoi 
de wstx:Aborted a Fapplication cliente, enregistree pour le protocole de terminaison avec acquittement. 

Nous considerons que Fetape zero s'est achevee avec succes. Le coordinateur lance alors Fetape de 
preparation : il envoie wstx: Prepare a toutes les applications prestataires enregistrees au protocole de 
confirmation en deux etapes dans le contexte de la transaction. Les applications participantes 
renvoient toutes la notification d'achevement avec succes de la premiere etape wstx: Prepared ou bien 
wstx: Readonly. Si une seule des applications prestataires participantes renvoie wstx: Aborted, le coor- 
dinateur entame la procedure d'annulation decrite dans le paragraphe precedent. 

La premiere etape s'est terminee avec succes. Le coordinateur lance Fetape de confirmation : il 
envoie a toutes les applications qui ont repondu wstx: Prepared a la fin de la premiere etape le 
message wstx : Commi t. Le propre du protocole de confirmation en deux etapes est que toutes les appli- 
cations qui ont recu wstx : Prepa red doivent repondre wstx : Commi tted (eventuellement apres redemar- 
rage, suite a une panne franche). La transaction est alors achevee et confirmee. 

Le coordinateur peut continuer le protocole de terminaison avec acquittement avec Fapplication 
cliente en lui envoyant le resultat de la transaction (wstx Committed). II recoit ensuite F acquittement 
(wstx: Notified). 



Le protocole de coordination des activites 



Le modele de processus metier organise par activites est un modele hierarchique obtenu par decom- 
position recursive d'une activite en taches, les taches etant executees par des applications reparties 
sur un reseau. Chaque nceud de Farbre de decomposition des taches est pilote par un coordinateur, 
dans le cadre d'un contexte de coordination. Le role de coordinateur, a tous les niveaux intermediai- 
res de Farbre, peut etre delegue a un agent logiciel independant ou bien directement pris en charge 
par Fapplication qui execute la tache mere (par implementation des differentes interfaces coordina- 
teur). Par simplicite et sans perte de generalite, nous supposons par la suite que les applications qui 
executent les taches au niveau intermediaire implementent directement les differentes interfaces 
coordinateur necessaires a la coordination de leurs sous-taches. 

Le modele des activites exhibe les caracteristiques suivantes : 

• Une application qui execute une tache, et ce a n'importe quel niveau intermediaire de Farbores- 
cence de decomposition, decide dynamiquement des taches a declencher parmi les taches filles de 
la tache qu'elle est en train d'executer. 
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Une application, au cours de l'execution d'une tache, peut lever une exception qui peut etre 
rattrapee par 1' application qui execute la tache mere. Cette application peut declencher une autre 
tache fille de gestion d' exception, executee eventuellement par une troisieme application. 

Une application qui execute une tache peut abandonner F activite a tout moment et notifier sa 
defection a 1' application executant la tache mere. 

Une application, lorsqu'elle a acheve l'execution d'une tache, peut le signaler a 1' application qui 
execute la tache mere et rester en attente d' instructions. L' application qui execute la tache mere 
peut decider de clore la tache ou bien lui demander de declencher un traitement dit de compensation, 
qui agit comme une contre-passation par rapport a la tache terminee. 

Les taches feuilles de l'arbre de decomposition peuvent s'executer dans le cadre d'une transaction. 
Dans ce cas, 1' application qui execute la tache mere met en ceuvre directement, ou delegue a un 
coordinateur specialise, les protocoles de coordination des transactions. 
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Figure 20-9 

Arbre de decomposition d'une activite en taches. 

Un exemple d' arbre de decomposition d'une activite est presente figure 20-9. L' application executant 
la tache Tl pilote l'execution des taches Til, T12, T13 dans le cadre d'une transaction et met en 
ceuvre, par coordinateur interpose (qu'elle peut implementer directement), le protocole multilateral 
de confirmation en deux etapes. Elle peut envoyer une exception a 1' application qui execute la tache 
principale, et cette application peut ordonnancer l'execution de T2, tache de gestion des exceptions 
de Tl (par exemple, en cas d'echec de la transaction). L' application executant la tache T31 pilote 
l'execution des taches T311 et T312 dans le contexte d'une transaction. Apres execution reussie et 
confirmee de la transaction (T311 et T312), T3 peut lui demander l'execution de la transaction 
compensatoire (T313 et T314). T32 est le gestionnaire des exceptions de T31. 



La gestion des transactions 

Chapitre 20 

La creation d'un contexte de coordination d'activite 

Le contexte de coordination d'une activite est cree par un coordinateur prestataire du service d' acti- 
vation selon le protocole d' activation standard WS -Coordination. 

Le modele des activites fait une utilisation poussee de F element wscoor:CurrentContext de 
wscoor:CreateCoordinationContext : 

• Lorsque wscoor:CurrentContext ne contient aucune valeur, le contexte de coordination retourne 
par la reponse est celui d'une activite nouvelle. 

• Lorsque wscoor:CurrentContex contient un contexte de coordination, ce contexte est celui de la 
tache mere, et le contexte de coordination nouvellement cree represente toujours la meme activite 
globale, mais la reference du port du coordinateur est celle du coordinateur interpose. Par exemple, 
dans la figure 20-9, le contexte de coordination cree pour coordonner la transaction T11/T12/T13 
a le meme identifiant que celui qui coordonne 1' activite globale (celui-ci est passe comme valeur 
de wscoor:CurrentContext du message wscoor:CreateCoordinationContext) mais le coordinateur 
indique dans le nouveau contexte pour le service de registration (wscoor : Regi strati onServi ce) est 
le coordinateur interpose, utilise parTl pour coordonner la transaction. 

• Les mecanismes standards d' extension permettent d'enrichir les contextes de coordination avec les 
informations complementaires, par exemple de gestion de l'arbre des contextes de coordination. 

Les protocoles bilateraux 

WS-Transaction-BA definit deux protocoles bilateraux (entre coordinateur et participant) de coordi- 
nation d'activite : 

• le protocole bilateral d' accord {BusinessAgreement), employe lorsque le participant sait detecter 
l'achevement de sa contribution a F activite en cours ; 

• le protocole bilateral d' accord avec terminaison (BusinessAgreementWithComplete), employe 
lorsque le participant est dependant du coordinateur pour savoir si sa contribution a 1' activite en 
cours est achevee. 

Les identifiants des protocoles bilateraux WS-Transaction-BA sont presentes dans le tableau suivant : 
Tableau des identifiants des protocoles bilateraux WS-Transaction-BA 



Protocole 


Identifiant 


Accord 


http://schemas.xmlsoap.org/ws/2002/08/wsba/BusinessAgreenient 


Accord avec term. 


http://schemas.xmlsoap.org/ws/2002/08/wsba/BusinessAgreementWithComplete 



Les protocoles bilateraux WS-Transaction-BA sont definis de la meme facon que les protocoles WS- 
Transaction-AT : par un couple d' interfaces (coordinateur, participant), un graphe d' etats et des 
regies. Les diagrammes d'etat que nous allons montrer dans les figures sont simplifies, car ils ne 
comprennent ni les etats et messages d'erreurs du protocole, ni les etats de defaillance de l'echange. 

Tous les messages definis dans les protocoles bilateraux WS-Transaction-BA sont de type wsba : Noti - 
f i cati on, dont la definition est identique a wstx: Noti f i cati on (voir la section « Le protocole de coor- 
dination des transactions »). 
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Tous les graphes d'etats des protocoles bilateraux rentrent dans Fetat Active des Fenregistrement du 
participant aupres du coordinateur (wscoor : Regi ster) avec l'identifiant du protocole. 

Le protocole bilateral d'accord 

Le protocole bilateral d'accord permet a F application qui execute une tache (qui, selon notre hypo- 
these simplificatrice, joue le role de coordinateur d'un contexte de coordination subordonne) de coor- 
donner F execution d'une tache fille. Le protocole est adapte au mode de fonctionnement dans lequel 
F application participante (qui execute la tache fille) entre dans le contexte de coordination pour 
executer une tache dont elle maitrise la condition de terminaison. Une illustration du diagramme 
d'etat du protocole bilateral d'accord est presentee figure 20-10. 
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Figure 20-10 

Protocole bilateral d'accord. 



Voici F interface participant : 

<wsdl :portType name=" Business Agreement Pa rtici pant PortType"> 
<wsdl :operation name="Cancel "> 

<wsdl : input message="wsba: Cancel "/> 
</wsdl :operation> 
<wsdl :operation name="Close"> 

<wsdl :input message="wsba:Close"/> 
</wsdl :operation> 
<wsdl :operation name="Compensate"> 

<wsdl :input message="wsba:Compensate"/> 
</wsdl :operation> 
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<wsdl :operation name="Forget"> 

<wsdl :input message="wsba:Forget"/> 
</wsdl :operation> 
<wsdl :operation name="Unknown"> 

<wsdl :input message="wsba:Unknown"/> 
</wsdl :operation> 
<wsdl roperation name="Error"> 

<wsdl :input message="wsba:Error"/> 
</wsdl :operation> 
</wsdl :portType> 

Et voici maintenant 1' interface coordinate ur : 

<wsdl :portType name="BusinessAgreementCoordinatorPortType"> 
<wsdl :operation name="Completed"> 

<wsdl :input message="wsba:Completed"/> 
</wsdl :operation> 
<wsdl :operation name="Exited"> 

<wsdl :input message="wsba:Exited"/> 
</wsdl :operation> 
<wsdl :operation name="Faul ted"> 

<wsdl :input message="wsba:Faulted"/> 
</wsdl :operation> 
<wsdl :operation name="Compensated"> 

<wsdl : input mess age="wsba: Compensated "/> 
</wsdl :operation> 
<wsdl :operation name="Closed"> 

<wsdl : input message="wsba:Closed"/> 
</wsdl :operation> 
<wsdl :operation name="Repl ay"> 

<wsdl :input message="wsba:Replay"/> 
</wsdl :operation> 
<wsdl :operation name="Unknown"> 

<wsdl :input message="wsba:Unknown"/> 
</wsdl :operation> 
<wsdl :operation name="Error"> 

<wsdl :input message="wsba:Error"/> 
</wsdl :operation> 
</wsdl :portType> 

L' application participante a recu un message applicatif qui donne lieu a l'execution d'une tache dans 
le contexte de coordination indique dans l'en-tete du message. L' application participante s'enregistre 
dans le contexte de coordination dont Fidentifiant du protocole est BusinessAgreement et se retrouve 
dans l'etat Active du protocole bilateral d' accord. 

L' application participante a acheve l'execution de la tache. Lorsque la nature de la tache ne demande 
pas la continuation de la participation a l'activite, l'application participante envoie un message 
Exited au coordinateur qui amene le protocole a l'etat final (Ended) et sort du contexte de coordina- 
tion. Un exemple de ce comportement est l'execution d'une tache ancillaire, comme l'inscription 
dans un journal d'un etat applicatif. 
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En revanche, si la nature de la tache demande que F application participante reste dans le protocole et 
le contexte de coordination en attente d'instruction de la part du coordinateur, 1' application partici- 
pante envoie au coordinateur le message Compl eted. 

Si le coordinateur considere que la contribution de 1' application participante, dans le cadre de ce 
contexte de coordination, est terminee, il envoie le message Close. Le participant envoie en reponse 
un message CI osed et termine sa participation au protocole et au contexte de coordination. 

A Finverse, le coordinateur peut demander a l'application participante l'execution d'une tache 
compensatoire de la tache terminee avec succes. Dans ce cas, il envoie le message Compensate. Le 
participant execute la tache compensatoire et, lorsqu'elle se termine avec succes, envoie le message 
Compensated. 

En cas de defaillance, lorsque l'execution de la tache primaire ou de la tache compensatoire est en 
echec, le participant envoie le message Faul ted. Le coordinateur envoie en reponse le message Forget 
qui clot la participation de l'application au protocole et au contexte de coordination. 

Le message Faulted peut contenir un element wsba:ExceptionElement, dont la definition dans le 
schema wsba est la suivante : 

<xsd: compl exType name="ExceptionType"> 
<xsd:sequence> 
<xsd: element name= "Target Protocol Service" type="wsu:PortReferenceType"/> 
<xsd:element name="ExceptionIdentifier" type="xsd:string"/> 
<xsd:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs=" unbounded "/> 
</xsd:sequence> 

<xsd:anyAttribute namespace="#other" processContents="lax"/> 
</xsd: compl exType> 
<xsd: element name=" Except ion Element" type="wsba: Except ionType"/> 

L'exception est traitee par une sous-tache de la tache mere executee par un gestionnaire d'exception. 

Le coordinateur, au moment de l'execution de la tache primaire de la part du participant, lorsqu'il n'a 
pas encore ete notifie de la terminaison reussie (Compl eted) ou de l'echec (Faul ted) de la tache, peut 
decider la suppression de la tache. II envoie alors le message Cancel au participant. Le participant est 
capable de supprimer la tache, c'est-a-dire qu'il est capable de mettre en ceuvre une procedure d' arret 
et de terminaison « propre ». A la fin de l'execution de cette procedure, il envoie le message Cancel ed 
au coordinateur, et termine sa participation au protocole et au contexte de coordination. 

La nature asynchrone et full-duplex (les messages Completed et Cancel peuvent se superposer) du 
protocole d' accord demande le traitement d'un certain nombre de situations de conflit : 

• Conflit entre Exited et Cancel : le message Exited est gagnant (le protocole passe aYetat Ended) et 
le message Cancel est ignore par le participant et oublie par le coordinateur. 

• Conflit entre Completed et Cancel : le message Completed est gagnant (le protocole passe a l'etat 
Completed) et le message Cancel est ignore et oublie. 

• Conflit entre Faulted et Cancel : le message Faulted est gagnant (le protocole passe a l'etat 
Faulted) et le message Cancel est ignore et oublie. 
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II n'y a pas d'ambigui'te, car, selon le protocole : 

• pour le coordinateur, le message recu Exited I Completed I Faulted est une reponse erronee au 
message envoye Cancel ; 

• pour le participant, le message recu Cancel est une reponse erronee au message envoye Exited I 
Completed I Faulted. 

Le protocole bilateral d'accord avec terminaison 

Le protocole bilateral d'accord avec terminaison permet a l'application executant une tache (qui, 
selon notre hypothese simplificatrice, joue le role de coordinateur d'un contexte de coordination 
subordonne) de coordonner l'execution d'une tache fille. Le protocole est adapte au mode de fonc- 
tionnement dans lequel l'application participante (qui execute la tache fille) entre dans le contexte de 
coordination pour executer une succession a priori illimitee de traitements (voir figure 20-11). 
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Figure 20-11 

Protocole bilateral d'accord avec terminaison. 



Les interfaces sont les memes que celles du protocole bilateral d'accord « simple », la seule difference 
etant que l'interface participant prend en plus en charge F operation Compl ete : 

|<wsdl :operation name="Complete"> 
<wsdl :input message="wsba:Complete"/> 
</wsdl :operation> 

La difference avec le protocole d'accord « simple » reside dans le fait que, si le participant ne fait pas 
defection au protocole et au contexte de coordination (Exi ted), il peut recevoir d'autres messages appli- 
catifs qui donnent lieu a l'execution d'autres traitements dans le meme contexte de coordination, 
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jusqu' a reception du message Compl ete de la pail du coordinateur. A la reception de ce message, le parti- 
cipant met en ceuvre les procedures d' arret de sa contribution a F activite dans le contexte de coordina- 
tion courant et envoie le message Compl eted au coordinateur. Le reste du protocole est identique au 
protocole d' accord « simple ». 

Dans l'etat Completing, les messages Cancel, Exited et Faulted amenent aux memes etats que dans 
l'etat Active, et les conflits entre Cancel d'un cote et Exited, Completed ou Faulted de 1' autre sont 
regies de la meme facon. 

Le pilotage d'une tache transactionnelle 

Nous allons decrire, a l'aide de la figure 20-12, 1' execution d'une transaction, pilotee au moyen du 
protocole multilateral de coordination WS-Transaction-AT, dans une activite pilotee au moyen du 
protocole bilateral d' accord WS-Transaction-BA. 

Dans le cadre d'une activite (par exemple, celle dont le graphe de decomposition est illustre 
figure 20-9), l'application A recoit un message applicatif ens : Exec (Q) qui provoque l'execution de 
la tache T31. Le message contient dans l'en-tete un contexte de coordination (ayant comme port de 
registration celui du coordinateur rattache a T3) avec 1'identifiant de WS-Transaction-BA (http:// 
schemas.xmlsoap.org/ws/2002/08/wsba) comme valeur de wscoor:CoordinationType. L'application 
s'enregistre aupres du coordinateur indique pour participer au protocole bilateral d' accord Business- 
Agreement (0). 

L'execution de la tache T31 demande la mise en ceuvre d'une transaction distribute composee des 
tachesT311 et T312, executees par les applications Bj etB 2 . L'application A demande a un autre 
coordinateur, qui va jouer le role de coordinateur interpose, la creation d'un contexte de coordination 
subordonne avec comme valeur de wscoor:CoordinationType, 1'identifiant de WS-Transaction-AT 
(http://schemas.xmlsoap.org/ws/2002/08/wstx). Dans le message de creation, wscoor:Current- 
Context reference le contexte de coordination dans lequel A est enregistre (0). 

L'application A s'enregistre aupres du coordinateur interpose pour participer au protocole bilateral 
de terminaison WS-Transaction-AT Completion (0). 

L'application A passe le contexte subordonne aux applications B { et B 2 dans les en-tetes des messa- 
ges applicatifs (ens: Start) qui demarrent les traitements. Les applications Bj etB 2 s'enregistrent 
aupres du coordinateur interpose pour participer au protocole bilateral de confirmation en deux 
etapes WS-Transaction-AT 2PC (©). 

Le deroulement de la transaction est identique a celui decrit dans la section « Relation entre les 
niveaux de protocoles » et illustre figure 20-8. Le protocole de cooperation entre les applications se 
deroule (0) correctement et le coordinateur interpose pilote le protocole de confirmation en deux 
etapes (0). 

Lors de la notification de la confirmation de la transaction (wstx: Committed), l'application A entame 
l'execution du protocole d' accord WS-Transaction-BA BusinessAgreement avec son coordina- 
teur (©) par l'envoi du message wsba : Compl eted. Le coordinateur execute le protocole d'accord dans 
le cas de cloture « normale » du protocole et du contexte de coordination principale. 
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Figure 20-12 

Activite qui gere line tdche transactionnelle achevee avec succes. 



Examinons quelques cas (Tissues differentes pour la tache T31 (voir figure 20-9, ces cas ne sont pas 
directement represented dans la figure 20-12) : 

• L' application B : signale une situation d'echec de la tache T311 via le message wstx: Aborted au 
coordinateur interpose, avant que celui-ci n'envoie le message wstx: Prepare. Le coordinateur 
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interpose doit coordonner l'annulation de la transaction. Si l'application A s'etait egalement enre- 
gistree pour participer au protocole de notification de Tissue {NotifiedOutcome) aupres du coordi- 
nates interpose, elle recevrait immediatement la notification de l'annulation. Sinon, elle initie le 
protocole de confirmation en deux etapes et recoit de la pail du coordinates interpose, comme 
reponse au message wstx: Commit, le message wstx:Aborted. L'application A envoie au coordina- 
tes principal le message wsba: Faulted et celui-ci repond par wsba: Forget. La tache T31 est 
« oubliee ». Le message wsba : Faul ted contient un element wsba : Excepti onEl ement et le coordinates 
au niveau T3 ordonnance la tache T32. 

• Le coordinates principal envoie le message wsba: Cancel a l'application A. Ce message est recu 
avant qu'elle n'envoie le message wstx:Commit au coordinates interpose. L'application A envoie 
le message wstx: Roll back au coordinates interpose qui se charge d'annuler la transaction, en 
repercutant le wstx: Roll back aux applications B[ etB 2 . Le coordinates interpose envoie 
wstx:Aborted a A, qui envoie wsba:Canceled a son coordinates. La tache T31 est supprimee. 

• Le coordinates principal envoie le message wsba : Cancel a l'application A. Ce message lui arrive 
apres qu'elle ait initie le protocole d'achevement avec le message wstx: Commit. Le coordinates 
interpose envoie comme reponse wstx: Aborted, car il y a eu arret par echec de la tache executee 
par B 2 . L'application A peut retosner « par chance » au coordinates principal wsba : Cancel ed. La 
tache T3 1 est supprimee. 

• Le coordinates principal envoie le message wsba : Cancel a l'application A. Ce message lui arrive 
apres qu'elle ait initie le protocole de terminaison avec le message wstx: Commit. Le coordinates 
interpose envoie comme reponse wstx: Committed. En application de la regie de resolution de 
conflit de la specification, A emet wsba : Compl eted, car la tache T31 ne peut plus etre supprimee, la 
transaction qu'elle pilote ayant ete confirmee. Le coordinates principal se replie sur la strategie de 
contre-passation : il emet done le message wsba Compensate. L'application A « sait » batir une 
transaction compensatoire (T313 et T314) qui suit le meme protocole de coordination que la tran- 
saction primaire (creation d'un nouveau contexte de transaction, enregistrement des applications 
participantes aupres d'un coordinates interpose, etc.). Si Tissue de la transaction compensatoire 
est wstx:Committed, l'application A envoie wsba Compensated au coordinates principal: la 
tache T31 est « compensee ». Sinon (Tissue est wstx:Aborted), l'application A envoie 
wsba: Faul ted avec une exception et le coordinates repond avec wsba: Forget. La tache T31 est 
oubliee et la tache T32 de gestion des exceptions est ordonnancee. 



Conclusion 

La gestion de transactions et d'activites constitue T infrastructure qui permet Tagregation de services 
Web au moyen de processus metier a un niveau eleve de qualite de service. 

WS -Coordination et WS-Transaction sont deux specifications simples et bien construites. Elles 
ciblent les sujets cles, peuvent atteindre rapidement la matsite et done faire Tobjet d' implementations 
fiables et performantes. 

Une zone insuffisamment developpee des technologies d'infrastructure des services Web reste la 
gestion de Techange fiable, notamment en relation avec la gestion des transactions et des activites 
reparties. II faut rappeler que les protocoles de cooperation, ainsi que les protocoles de coordination 



La gestion des transactions 

Chapitre 20 

comme WS -Coordination et WS-Transaction sont mis en ceuvre exclusivement via des protocoles de 
communication entre agents logiciels autonomes. La fiabilite des communications est done une 
exigence de base pour que la cooperation et la coordination fonctionnent correctement. Nous avons 
vu que les specifications WS -Coordination et WS-Transaction sont obligees dans certains cas de 
rappeler le sujet (qu'elles ne sont pas censees traiter directement) et meme de prendre en charge a 
leur niveau des mecanismes de type « accuse de reception ». 

La maturite et le niveau d'integration de Fensemble des technologies d' infrastructure, comprenant la 
gestion de l'echange fiable, la gestion de la securite, la gestion des transactions et des activites reste 
le facteur cle de l'essor des services Web. 

L amelioration de la productivite du developpement de services Web passe par la disponibilite de 
formalismes de haut niveau pour l'agregation des services et la mise en ceuvre des processus metier 
(voir le chapitre 21, « Gestion des processus metier »). Mis a part le probleme de la normalisation, 
qui ne touche d'ailleurs que les protocoles de cooperation entre applications dans un processus (ce 
qui est appele aujourd'hui choregraphie), ces formalismes ne pourront etre reellement utilises pour 
mettre en ceuvre des processus metier critiques seulement lorsque les technologies d' infrastructure 
(l'echange fiable, la securite, les transactions) atteindront les niveaux necessaires de fiabilite et de 
performance. 
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L' emergence des technologies liees aux services Web a immanquablement reintroduit la problema- 
tique de la gestion des processus metier. En effet, la granularite d'un service Web peut etre variable 
et couvrir un domaine tres localise (service convertisseur francs vers euros et euros vers francs, par 
exemple) ou tres large (service d'annuaire UDDI). Un service Web peut aussi faire appel a d'autres 
services Web pour implementer les fonctions qu'il est cense offrir : ce mecanisme d'agregation de 
services peut d'ailleurs etre utilise sur plusieurs niveaux, a l'interieur du service de niveau le plus 
externe. De meme, il est possible d'enchainer differents services Web pour aboutir a la mise en 
ceuvre d'un processus metier partiel ou complet (comme passer un ordre d' achat de fournitures par 
exemple). 

Les technologies existantes, SOAP, WSDL et UDDI, permettent de mettre en ceuvre des services 
Web qui constituent autant d'unites elementaires (« atomiques ») a l'interieur de processus metier 
plus ou moins complexes. Cependant, ces technologies basiques sont insuffisantes pour prendre en 
compte et decrire les interactions entre toutes les unites elementaires qui composent les processus a 
automatiser. II est done devenu indispensable de poursuivre dans le domaine de la normalisation des 
technologies afin d'etre en mesure de decrire ces interactions entre services Web. 

Nous avons traite dans les trois chapitres precedents les services d' infrastructure (fiabilite de 
l'echange, securite, transactions) qui mettent en ceuvre le cadre technique dans lequel les interactions 
entre services Web d'une part, et avec leurs clients d' autre part, peuvent se derouler dans le respect 
des exigences de qualite de service (fiabilite, disponibilite, securite, performance) qui s'imposent aux 
processus metier critiques. Ce chapitre explique comment decrire, de preference au moyen d'un 
langage de haut niveau, les processus metier, et comment faire en sorte que cette description soit 
executable, a savoir prise en compte par un moteur d'execution dans le cadre de 1' infrastructure 
technique assurant la fiabilite, la securite et la gestion des transactions. 

L'agregation de services Web en processus metier est souvent decrite sous les termes de conversa- 
tion, choregraphie ou orchestration de services Web. Ces nouveaux termes rejoignent la notion de 
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workflow, voire de workflow documentaire, appliquee aux processus de gestion operationnelle ou 
aux processus de gestion de la documentation de l'entreprise. Les technologies de workflow ont ete 
utilisees dans les architectures applicatives de type client/serveur notamment, et plus recemment dans 
les logiciels d'EAI (Enterprise Application Integration). Le W3C, qui a cree, en Janvier 2003, le 
groupe de travail Web Services Choreography Working Group dedie a cette question, a retenu 
le terme de « choregraphie » dans la charte de ce groupe (voir http://www.w3.org/2003/01/wscwg-charter). 

La gestion « traditionnelle » des processus metier ou BPM (Business Process Management dans la 
litterature anglo-saxonne) couvre tous les aspects du cycle de vie des processus a Finterieur de 
l'entreprise : 

• la modelisation, 

• le developpement, 

• le deploiement, 

• 1' exploitation, 

• 1' administration, 

• le pilotage. 

Une nouvelle forme d' architecture des processus metier interentreprises, portee par l'emergence des 
technologies XML, se situe a un point de confluence entre plusieurs modeles d' organisation ante- 
rieurs : l'EDI (Electronic Document Interchange ou echange de donnees informatise), le B2B (Busi- 
ness to Business) et FEAI. La transition entre ces differents modeles s'effectue d'ailleurs de maniere 
tres progressive, par hybridation technologique. La plupart des produits commerciaux qui prennent 
en charge ces anciens modeles ont integre progressivement le langage XML, et depuis quelque temps 
commencent egalement a prendre en charge les technologies qui en derivent, specifiques aux services 
Web, telles que le protocole SOAP ou le langage de description de services Web WSDL. 

Cette nouvelle forme d' architecture, concue pour permettre le deploiement et 1' interconnexion des 
systemes d'information des entreprises a travers Internet, parfois nominee IAI (Internet Application 
Integration) par opposition a l'EAI, est plus justement nommee AOS (architecture orientee services 
ou SOA : Service Oriented Architecture, en anglais). 

Cette nouvelle architecture efface la distinction conceptuelle entre processus metier intra-entreprises 
et interentreprises, distinction qui s'etait traduite dans le passe par des gammes differentes d'outils 
logiciels souvent incompatibles entre eux. Cette distinction se transforme en une pure question de 
droits, d'habilitations et de controles d'acces aux ressources internes des entreprises participant au 
processus. 

La conception et le developpement de nouvelles architectures de ce type necessitent, de la part de la 
communaute des acteurs qui prennent en charge les technologies de services Web, un nouvel effort 
important en termes de specification. En effet, apres avoir defini les elements indispensables au deve- 
loppement de services Web unitaires que sont les specifications SOAP, WSDL et UDDI, il devient 
imperatif de formaliser la facon dont ces services Web peuvent etre combines entre eux, afin de 
proposer des processus metier complets et operationnels de bout en bout. 

Ces nouvelles specifications devront meme pouvoir prendre en compte de nouvelles problematiques 
telles que la securite des processus geres, Fintegrite trans actionnelle et le respect de clauses predefinies, 
contractuelles et de qualite de service. 
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Specifications initiales 

Le champ de la modelisation des processus metier se trouve brusquement place sous les feux de la 
rampe depuis le debut de Fannee 2002. De nombreuses initiatives ont vu le jour, parmi lesquelles : 

• WfMC (Workflow Management Coalition) : historiquement la plus ancienne et attachee au deve- 
loppement de standards dans le domaine du workflow (http://www.wfmc.org) ; 

• BPMI (Business Process Management Initiative) : creee sous la houlette de la societe Intalio (http:/ 
IwwwMaWo.com) et a l'origine de la specification BPML (Business Process Modeling Language) et 
BPQL (Business Process Query Language) ; 

• WSCI (Web Services Choreography Interface) : initiative proposee par BEA, Intalio, SAP et Sun 
Microsystems pour prendre en compte la collaboration d' application a application qui s'est 
concretisee par une note (8 aout 2002) au W3C ; 

• WSCL (Web Services Conversation Language) : specification adressee le 14 mars 2002 par 
Hewlett-Packard au W3C, sous forme d'une note, et dont l'objectif consiste a decrire la sequence 
d' interactions possibles avec un service Web particulier ; 

• WSFL (Web Services Flow Language) : il s'agit d'une proposition effectuee par IBM en matiere 
de composition de services Web ; 

• XLANG : extension de la specification WSDL, creee par Microsoft et implementee dans le produit 
BizTalk Server 2002 ; 

• XPDL (XML Pipeline Definition Language) : specification d'origine Sun Microsystems, soumise 
au W3C et enregistree sous forme d'une note datee du 28 fevrier 2002, dont la finalite consiste a 
decrire des relations de traitement entre ressources XML ; 

• ebXML (Electronic Business using extensible Markup Language) : institute a F initiative d'un 
organisme des Nations Unies, FUN/CEFACT (United Nations Centre for Trade Facilitation and 
Electronic Business) (voir http://www.ebxml.org et http://www.unece.org/cefact). Cette organisation 
propose la specification BPSS (Business Process Specification Schema). 

Toutes ces initiatives, dont certaines sont prises en charge par des produits commerciaux (Microsoft, Inta- 
lio, etc.), ne semblaient pas devoir aboutir rapidement a la mise a disposition d' implementations utilisa- 
bles a grande echelle. Nous sommes en fait en presence d'un recentrage des priorites et d'une reorgani- 
sation des activites, qui se sont encore recemment manifestes par Fannonce, effectuee par Microsoft et 
passee relativement inapercue, de stopper Factivite de Forganisation BizTalk.org et de fermer le site Web 
le 19 juillet 2002 (Fancien site Web http://www.biztalk.org redirige maintenant vers le site Microsoft dedie 
au produit BizTalk Server de Microsoft : http://www.microsoft.com/biztalk). Selon Microsoft, la raison offi- 
cielle est que cette organisation, creee a l'origine pour susciter F emergence et le developpement des 
schemas XML, n'est plus necessaire du fait de la banalisation d'XML et des schemas. 

Cette decision illustre un changement majeur dans les priorites. On peut effectivement considerer que 
Fargument avance par Microsoft, c'est-a-dire Futilisation d'XML comme langage universel de repre- 
sentation des donnees et des documents, est acquis : il suffit d' observer la floraison de vocabulaires 
XML metier apparus ces deux dernieres annees, ainsi que le nombre croissant d' organisations char- 
gees de gerer et de faire evoluer ces referentiels. Ces schemas XML sont maintenant utilises pour 
decrire et formaliser les echanges entre partenaires economiques et industriels. La priorite s'est 
deplacee aujourd'hui vers la description de la dynamique de ces echanges et de Fenchainement des 
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messages XML qui les supportent. II ne s'agit plus maintenant de traiter de questions qui relevent du 
quoi (l'objet de Fechange), mais plutot des aspects qui concernent le comment (les conditions), le 
quand (Fordonnancement) et le qui (les partenaires) de Fechange. C'est la raison pour laquelle le 
concept, deja ancien, de processus metier s'est de nouveau trouve au centre des preoccupations. 

Outre les specifications a vocation generaliste citees precedemment, il convient egalement de citer les 
travaux du consortium RosettaNet (voir http://www.rosettanet.org) dans le domaine des industries elec- 
troniques. Depuis fevrier 1998, cette organisation s'est engagee dans la definition de vocabulaires 
XML specifiques a ce secteur industriel, mais s'est egalement attachee a formaliser les processus 
metier en vigueur sous la forme de PIP (Partner Interface Processes). II faut d'ailleurs signaler que 
ces processus modelises sont publies dans l'annuaire public UDDI. Les travaux de cette organisation 
sont souvent cites en exemple et sont largement implementes. Ainsi, la societe Intel a annonce, dans 
un communique publie le 10 decembre 2002 (voir http://www.rosettanet.org/RosettaNet/Rooms/DisplayPa- 
ges/LayoutDoc ?PressRelease=com. webridge. entity. Entity[OID[5F4F00 1 CC0F5724680E959C962EF3BC2]]), que 
plus de 10 % de ses commandes clients 2002 (plus de trois milliards de dollars, soit a peu pres autant 
en euros), et de ses achats fournisseurs (plus de deux milliards de dollars, soit a peu pres autant en 
euros), ont ete realises grace a 1' usage de la technologie RosettaNet. Ces volumes represented plus 
de trente mille transactions par mois, realisees avec plus de quatre-vingt-dix clients et fournisseurs 
repartis dans dix-sept pays. 



Fondement theorique des specifications XLANG et BPML : n-calcul 

Les langages XLANG et BPML font tous les deux appel aux principes du rc-calcul (ou pi-calcul). Le n-calcul est un 
langage fonctionnel qui a ete developpe dans les annees quatre-vingt-dix par Robin Milner (voir http://move.to/ 
mobility). II est utilise pour decrire des systemes de processus mobiles. Le ic-calcul est egalement a la base de la 
semantique d'un langage tel qu'Erlang, developpe par la societe Ericsson et utilise dans le domaine des applications 
de telecommunication. 



Nouvelles specifications 

Une annonce commune de BEA, IBM et Microsoft, dans le domaine du BPM (Business Process Mana- 
gement) effectuee durant Fete 2002 a introduit des changements importants. En effet, ces trois acteurs 
ont publie le 9 aout 2002, simultanement sur leurs sites Web respectifs, un ensemble de trois nouvelles 
specifications complementaires destinees a prendre en compte la gestion de processus metier via les 
services Web (voir annonce IBM : http://www-3.ibm.com/software/solutions/webservices/pr20020809.html). 

Les trois nouvelles specifications sont : 

• WS-Coordination (Web Services Coordination) est la specification d'un metaprotocole de coordi- 
nation entre applications qui est utilise par des protocoles de coordination specifiques. Elle prend 
en compte notamment les aspect d' activation et de registration des applications participantes a un 
contexte de coordination. WS-Coordination est presentee chapitre 20. 

• WS-Transaction (Web Services Transaction) definit deux protocoles de coordination, adaptes a la 
mise en ceuvre de transactions atomiques {Atomic Transaction) et d'activites metier {Business 
Activity). WS-Transaction est presentee chapitre 20. 
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BPEL4WS (Business Process Execution Language for Web Services) remplace les precedentes 
specifications XLANG de Microsoft et WSFL d'IBM. Elle definit un langage de description des 
modalites d' interaction de processus metier intra-entreprises (intranet) ou interentreprises 
(extranet, internet). Une fois ces processus definis, la coordination technique des applications, en 
vue d'assurer Fintegrite, la fiabilite et la securite du processus est assuree par les protocoles definis 
dans les deux autres specifications WS -Coordination et WS-Transaction (la specification WS- 
Security, presentee chapitre 19, est aussi appelee a contribution pour Fintegrite des messages). 



Serveurs d'orchestration : futur des serveurs d'applications ? 

Ces trois specifications ont ete produites et publiees par BEA, IBM et Microsoft. II faut remarquer que ces trois 
entreprises dominent largement le marche des serveurs d'applications. 



Cette annonce a ete doublee des le 12 aout 2002, de la part d'IBM, par Fannonce de la publication 
simultanee d'une implementation de reference de BPEL4WS sur le site d'alphaWorks : BPWS4J 
(Business Process Execution Language for Web Services Java Run Time) telechargeable a Fadresse 
http://www.alphaworks.ibm.com/tech/bpws4j, d'une part, et par celle de la mise en ligne d'une nouvelle 
version du WSTK (Web Services Tool Kit), la version 3.2.1 qui integre une demonstration de la mise 
en ceuvre de ces trois nouvelles specifications, egalement accessible sur le site d'IBM alphaWorks a 
Fadresse http://www.alphaworks.ibm.com/tech/webservicestoolkit (voir annonce : http://www-3.ibm.com/software/ 
solutions/webservices/pr200208 12. html) . 

Puis, c'est le tour de Microsoft d'annoncer, le 26 aout 2002, la disponibilite d'une nouvelle boite a 
outils, le WSDK (Web Services Development Kit), qui implemente dans un premier temps en version 
preview, les specifications WS-Security, WS-Routing, WS -Attachments et DIME (voir annonce : 
http://www.microsoft.com/presspass/press/2002/aug02/08-26wsdkpr.asp). Cette boite a outils, destinee a four- 
nir aux developpeurs des implementations intermediates de nouvelles specifications, entre les 
versions officielles du framework .NET ou de Visual Studio .NET, un peu a la maniere du WSTK 
d'IBM, devrait prochainement inclure les implementations des trois nouvelles specifications liees a 
F orchestration de services Web. 



Effervescence dans le monde du BPM 

Ces trois nouvelles specifications ont provoque une certaine effervescence dans le monde du BPM et 
ont introduit une certaine confusion car elles s'ajoutent aux specifications preexistantes et presentent 
certains recouvrements avec celles-ci. 

Parmi ces elements de confusion, on peut noter les faits suivants : 

• BEA et IBM sont membres de F initiative BPMI, a Forigine de la specification concurrente BPML. 

• BEA est Fune des societes a Forigine de la specification WSCI, sur laquelle s'appuie la version 
finale de BPML, publiee en juin 2002. 

• Les specifications WS-Transaction et WS -Coordination recouvrent partiellement les caracteristiques 
de la specification BTP de FOASIS, dont BEA est a Forigine. 

A ce jour, les reactions ont ete mitigees : le WfMC a pris acte de Farrivee de la specification 
BPEL4WS, mais considere que sa propre specification Wf-XML est plus complete (voir http:// 
www.wfmc.org/pr/BPEL4WS.htm). L'initiative BPMI, quant a elle, a publie, des le 15 aout, sa position 
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dans un document (Position Paper) intitule BPMUBPEL4WS - A Convergence Path toward a Stan- 
dard BPM Stack (voir http://www.bpmi.org/downloads/BPML-BPEL4WS.pdf). Selon son opinion, l'organisa- 
tion BPMI considere que BPML et BPEL4WS sont tres similaires et que sa specification BPML 
constitue un surensemble de BPEL4WS. Egalement dans le domaine voisin de la gestion de transac- 
tions, la societe Choreology a annonce, le 14 aout 2002 (voir annonce : http://www.choreology.com/news/ 
140802_webservices.html), la prise en charge future des specifications WS-Transaction etWS -Coordina- 
tion par son nouveau produit Cohesions 1.0 (voir http://www.choreology.com/products/index.html) qui prend 
deja en charge la specification BTP (Business Transaction Protocol). 

Jeff Mischkinsky, de la societe Oracle, inquiet de la multiplicite des propositions et de la tournure des 
evenements, a demande au W3C, en septembre 2002, de constituer un groupe de travail pour choisir 
l'une des specifications comme reference ou de les combiner pour faire emerger un standard. Un vote 
sur cette proposition d' Oracle a ete organise lors d'une reunion du groupe de travail Web Services 
Architecture du W3C qui s'est tenue a Washington, le 12 septembre 2002. Ce vote, scinde en deux 
questions, a produit un resultat mitige : 

• a la premiere question, sur la necessite d'agir dans le domaine de 1' orchestration et de la choregra- 
phie, la reponse des intervenants a ete positive a l'unanimite ; 

• a la seconde question, sur le fait que ces actions soient entreprises dans le cadre du W3C, la reponse 
a ete positive, sans etre acquise a l'unanimite : seize voix pour, huit abstentions et une voix contre. 

Selon certaines indiscretions, deux des abstentions etaient des decisions de BEA et dTBM, et le vote 
contre emanait de Microsoft. En fait, les auteurs des trois dernieres specifications (BPEL4WS, WS- 
Transaction etWS -Coordination) se sont opposes a envisager une telle perspective. 

Cependant, le W3C a decide, en septembre 2002, de creer le groupe de travail Web Services Choreo- 
graphy au sein de son activite Web Services (voir http://www.w3.org/2002/ws). Cette idee, deja debattue 
au W3C avant Pete 2002, s'est finalement imposee, du fait de la precipitation des evenements et 
malgre cette opposition de BEA, IBM et Microsoft. Le W3C a done publie en consequence une 
premiere proposition de charte de fonctionnement de ce nouveau groupe de travail (voir http:// 
www. w3. org/2002/ws/arch/2/09/chor-proposal. html) . 

Cette charte prevoyait de fonder le travail de ce groupe sur la specification WSDL 1.2, d'une part, et 
sur les specifications BPSS, WSCL, BPEL4WS, BPML et WSCI, d' autre part. 

L agenda previsionnel de ce nouveau groupe de travail du W3C etait : 

• septembre/octobre 2002 : creation du groupe ; 

• octobre 2002 : organisation d'un atelier ; 

• mars 2003 : premier document (draft) de specification ; 

• novembre 2003 : recommandation finale ; 

• juin 2004 : dissolution du groupe de travail. 

Finalement, le groupe de travail Web Services Choreography a ete cree en Janvier 2003 et a publie sa 
charte definitive (voir http://www.w3.org/2003/01/wscwg-charter). Ce groupe de travail ne s'appuiera 
formellement que sur les specifications WSDL 1 .2 et WSCI. 
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Participants au groupe de travail Web Services Choreography du W3C 

Les societes et organisations, dont des membres participent a ce groupe de travail, sont les suivantes : BEA, 
Choreology, Cisco, Computer Associates, DSTC Pty, EDS, Enigmatec, Fujitsu, Hewlett-Packard, Hitachi, Intalio, 
IONA Technologies, Novell, Oracle, Progress Software, SAP AG, SeeBeyond Technology, Software AG, Sun 
Microsystems, University of Maryland, webMethods et W.W Grainger. 

II faut remarquer I'absence notable de deux des trois initiateurs des specifications BPEL4WS, WS-Transaction et 
WS-Coordination (IBM et Microsoft). Seul BEA a delegue un representant aupres de ce groupe de travail. Selon 
une version intermediaire de la charte du groupe de travail (novembre 2002), la specification BPEL4WS aurait ete 
prise en consideration si elle avait fait I'objet d'une soumission au W3C entre-temps. 



Le planning prevu montre un decalage global de trois a six mois, selon les taches, par rapport a 
1' agenda previsonnel (fin en decembre 2004). 

Toute cette effervescence montre que nous sommes loin d'un accord unanime dans ce domaine. II 
faut esperer que tous ces acteurs finiront par trouver un terrain d' entente, et que les synergies qu'ils 
pourront trouver permettront de degager un consensus autour d'une specification commune ou de 
plusieurs specifications coherentes entre elles. II s'agit la d'un element vital pour l'essor des techno- 
logies des services Web, en relation avec la gestion des transactions et la fiabilite des echanges. 

Services Web, processus metier, orchestration et choreographie 

Toutes ces initiatives ont pour objectif commun de proposer un langage de modelisation de processus 
metier. II s'agit de decrire ces processus, leurs interfaces statiques et leurs comportements dynami- 
ques, tout en restant independant de leurs implementations par les applications participantes. La prise 
en charge et 1' implementation de ces langages de modelisation permettent ainsi de proposer aux 
entreprises des moteurs de gestion de processus metier, parfois appeles BPMS (Business Process 
Management System). 

Processus metier 

Un processus metier decrit des interactions entre des agents (personnes, services, organisations) et 
des systemes d'information (logiciels, sous-systemes). Les differentes entites qui interagissent dans 
un processus donne sont les participants de ce processus. Le processus metier est determine par un 
objectif precis : produire une facture d' achat de fournitures, editer un catalogue electronique, etc. II 
est a la fois collaboratif et transactionnel, et peut etre compose d'activites automatisees aussi bien que 
manuelles. 

Un processus metier, dans le domaine des services Web : 

• repose sur la cooperation entre applications participantes « faiblement couplees » ; 

• peut etre de courte duree (et mis en ceuvre dans le cadre d'une transaction atomique) ou bien de 
longue duree (avec des etats intermediaires visibles) ; 

• peut echouer partiellement, declencher des situations d' exception et gerer des compensations ; 

• peut etre mis en ceuvre par l'enchainement de plusieurs transactions atomiques et/ou imbriquees. 
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Orchestration 



L' orchestration definit les interactions entre les applications qui participent au processus metier et 
l'enchainement de ces interactions. Les interactions sont decrites en termes de messages (envoyes 
et recus) et de traitements metier associes a remission (preparation) ou a la reception (traitement) 
de ces messages. 

L' orchestration est une description du processus du point de vue de Fune des entites participantes. II 
existe done autant d' orchestrations que de participants au processus. Par exemple, dans un systeme 
simple ou n'interviennent que deux applications qui jouent respectivement les roles de Facheteur 
(buyer) et du vendeur (seller), nous sommes en presence de deux orchestrations differentes selon le 
point de vue dans lequel nous nous situons. Si Fon se place dans la perspective de Facheteur, on peut 
considerer que Fon traite de F orchestration d'un processus de gestion des achats. En revanche, si Fon 
se place dans la perspective du vendeur, on peut penser que Fon considere la situation de F orchestration 
d'un processus de gestion des ventes. 

L' orchestration est Forganisation des traitements et des echanges de messages du point de vue d'une 
application participant au processus metier. 

Choregraphie 

Par ailleurs, pour que le systeme fonctionne, il est absolument necessaire que les messages echanges 
entre les deux applications soient non seulement structures de la meme maniere, mais de plus soient 
porteurs de la meme semantique. De meme, l'enchainement des echanges de messages doit etre mis 
en ceuvre de la meme maniere entre les deux orchestrations. 

Ici, nous nous situons done a un niveau de collaboration entre les participants de ces processus 
metier. II s'agit plutot de decrire une interface publique commune aux deux orchestrations. La chore- 
graphie permet d'exprimer la partition a jouer (les messages echanges et l'enchainement des echan- 
ges) et la repartition des roles (Qui envoie quel message ? Qui recoit quel message ?) entre les 
participants de ces processus metier. 

Le concept de choregraphie peut etre rapproche de la notion de conversation definie par Hewlett- 
Packard dans sa specification WSCL (voir plus loin). En effet, une description de conversation est un 
document XML qui specifie les messages echanges ainsi que l'enchainement de ces echanges. Cette 
description exprime Finteraction entre applications du point de vue d'un seul des participants, gene- 
ralement dans la perspective du fournisseur du service Web. Cependant, le modele de la conversation 
peut etre facilement reexprime du point de vue reciproque du consommateur du service Web par une 
simple transposition des interactions de type reception ou reception-emission en emission ou emission- 
reception. 

La choregraphie est done la description des echanges de messages et des enchainements de ces 
echanges entre applications participantes au processus metier. 
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Positionnement des specifications 

A la lumiere de la distinction orchestration/choregraphie que nous venons de faire, il est possible de 
montrer le positionnement relatif des dernieres specifications proposees. 

Positionnement des specifications BPEL4WS, BPML etWSCI 

Domaine BPEL4WS BPML-WSCI 

Collaboration publique entre participants (choregraphie) Processus abstraits BPEL4WS Interfaces WSCI 

Implementation privee des participants (orchestration) Processus executables BPEL4WS Processus BPML 

L'objectif des technologies de services Web est Finteroperabilite entre applications dont les imple- 
mentations sont heterogenes via la mise en ceuvre de protocoles et de technologies d'echange et de 
communication standardises. A la rigueur, des deux sujets appeles « choregraphie » et « orchestra- 
tion », seule la choregraphie releve de la technologie des services Web. Cela ne reduit evidemment 
pas Finteret que Ton peut porter au deuxieme sujet, a savoir un langage de pilotage de l'execution 
d' applications complexes qui interagissent avec des services Web. 

En fait, 1' orchestration est la mise en ceuvre d'un langage de scripting portable sur des plates-formes 
materielles et logicielles heterogenes. Ses avantages sont 1' augmentation de la productivite dans le 
cycle de mise en ceuvre d' applications complexes et Findependance des fournisseurs de plates- 
formes : c'est un domaine d'activite a priori independant des services Web. Le lien avec les technolo- 
gies des services Web apparait des que 1' orchestration d'un processus metier est implementee sous 
forme d'un service Web qui peut etre lui-meme invoque dans le contexte d'un autre processus metier 
dont le perimetre englobe le premier processus. 

Certaines propositions de specifications actuelles ainsi que les implementations disponibles et a venir 
prennent en charge en meme temps la choregraphie et 1' orchestration. Cette approche est absolument 
legitime en soi et s'explique en grande partie par le fait que les initiateurs de ces specifications 
operent dans le secteur des serveurs d' applications et de moteurs de workflow, mais elle pose cepen- 
dant deux problemes majeurs, qui sont : 

• une plus grande complexite des specifications, avec une partie sur les protocoles de cooperation 
entre participants et une autre sur la mise en ceuvre du workflow ; en outre, la partie orchestration 
de la specification doit en general tenir compte des approches et des systemes patrimoniaux des 
auteurs de ces specifications ; 

• une plus grande lourdeur dans Factivite de test et de validation de Finteroperabilite, deja suffi- 
samment ardue (voir chapitre 17), si cette activite doit egalement couvrir la portabilite de 
F orchestration. 

Model isation de la gestion des processus metier 

Les regies d' orchestration des services Web sont formalisees via des documents XML (scenarios 
BPEL, par exemple), de meme que leurs descriptions le sont par F intermediate de documents 
WSDL. 
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Globalement, un systeme de gestion de processus metier peut etre formalise tel que le suggere la 
figure 21-1 : 

Schematiquement, la cinematique de fonctionnement d'un tel systeme est la suivante : 

1. Une application cliente a besoin d'invoquer le service Web (WSO) pour son propre fonctionne- 
ment. Pour cela, elle invoque le moteur d'orchestration des services Web, eventuellement via 
l'utilisation d'une interface WSDL du service Web WSO. 

2. Le moteur d'orchestration exploite un moteur de recherche de services Web pour retrouver la 
description du service Web WSO ainsi que les regies d'orchestration correspondantes (deploiement 
local ou distant du service Web). 

3. Le moteur de recherche recupere la description du service Web WSO. Normalement, il s'agit d'un 
document WSDL, mais cette description peut avoir un autre format, y compris un format XML. 
Cette recherche s'appuie sur les implementations de systemes de decouverte de services Web de 
type UDDI, WSIL, etc. 

4. Le moteur de recherche retrouve la description des regies d'orchestration associee au service 
Web WSO dont la description a ete precedemment recuperee. Cette description peut etre formali- 
see par un document WSCL, par exemple. Les performances d'un tel moteur de recherche 
peuvent etre ameliorees par la mise en ceuvre d'un systeme de cache, identique a celui decrit dans 
la convention d'appel de la specification UDDI, par exemple. 

5. Le moteur d'orchestration decrypte les regies d'orchestration associees au service Web WSO et 
invoque les methodes de l'interface de ce service selon les sequences d'interaction decrites. Dans 
notre exemple, le service Web WSO a besoin d'utiliser (alternativement, successivement, en 
parallele, par composition, etc.) les fonctions offertes par le service Web WS1. Dans ce cas, le 
moteur d'orchestration reitere les etapes 2, 3 et 4 pour ce service. 

6. Voir etape 5. Les elements descriptifs du service Web WS2 sont recherches soit parce que la 
choregraphie decrite par les regies d'orchestration du service Web WSO l'exige, soit parce que les 
regies du service Web WS 1 l'imposent (encapsulation). 

7. Le moteur d'orchestration restitue a l'application cliente du service Web WSO soit le resultat 
attendu suite a l'invocation de la fonction initiale, soit une exception, eventuellement remontee 
en cascade en fonction de la pile d' execution du moteur. 

Remarquons que ce schema est tres generique et qu'il ne fait en rien reference a des methodes d'invo- 
cation synchrone ou asynchrone des services Web orchestras. Le moteur d'orchestration doit etre en 
mesure de prendre en charge, de maniere interoperable, des systemes de files d'attente de type JMS, 
MSMQ ou MQSeries par exemple, en attendant une infrastructure d'echanges fiable et asynchrone 
pour les services Web (voir le chapitre 18). De meme, il n'est pas fait ici mention de gestion de tran- 
sactions comtes ou longues, mais bien entendu, le moteur d'orchestration doit etre capable de gerer 
les parties transactionnelles modelisees dans la choregraphie d' ensemble. 
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Application fcumisseur WS1 



Application diente W30 




Application tou rnisseur WS2 



Figure 21-1 

Schema d'un systeme BPMS de type orchestration de services Web. 

Principales specifications en presence 

Comme nous Favons vu precedemment, un certain nombre de specifications s'attachent a standardi- 
ser le comportement dynamique des services Web et a definir ce que sont les regies de 1' orchestra- 
tion, de la choregraphie ou de la conversation selon la terminologie employee par ces referentiels. 

Nous allons ici nous attarder sur les specifications les plus recentes dans ce domaine. Nous n'entre- 
rons cependant pas dans les details de chacune de ces specifications. En effet, comme nous l'avons vu 
precedemment, le domaine du BPM est actuellement en effervescence et extremement morcele. De 
fait, aucune de ces specifications ne detient pour F instant une position dominante et les evolutions 
sont tres rapides. Par ailleurs, nous n'aurions pu resumer en quelques pages la description de 
l'ensemble de ces specifications. Enfin, il existe fort peu d' implementations de ces specifications, et 
lorsque celles-ci existent, elles demeurent relativement confidentielles. II nous semble done prefera- 
ble de decrire brievement les principales specifications susceptibles d'influencer l'avenir immediat 
de la normalisation dans ce domaine. 



BPEL4WS 



BPEL4WS (Business Process Execution Language for Web Services) constitue done le dernier effort en 
matiere de specification dans le domaine de la gestion de processus metier. Cette specification (parfois 
nommee BPEL) est appelee a remplacer les precedentes specifications XLANG de Microsoft et WSFL 
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d'IBM. Son objectif consiste a definir un langage de description du comportement de processus metier 
elabores a partir de services Web. Cette nouvelle specification etend le modele d'interaction des services 
Web et ouvre ainsi la voie vers la gestion de transactions metier. La specification BPEL4WS est asso- 
ciee a deux autres specifications, WS -Coordination et WS -Transaction, en charge d' assurer la coordina- 
tion et Fintegrite de ces processus metier. A l'heure de la redaction de cet ouvrage, ces trois specifications 
n'ont pas fait Fobjet d'une soumission a un organisme de normalisation. 

La specification BPEL4WS definit ses propres espaces de noms, prefixes par bpws, si nk et sref. Elle 
fait egalement appel a des elements des specifications WSDL et XML Schema, dont elle reference les 
espaces de noms et s'appuie egalement sur la specification XPath. 

BPEL4WS decrit le comportement d'un processus metier en fonction des interactions enfre ce 
processus et ses partenaires (partners). Ces interactions se realisent via des interfaces de services 
Web. La structure de la relation au niveau de F interface est encapsulee dans un lien de service 
(service link). 

Le langage defini par BPEL4WS peut etre utilise de deux facons : 

• soit pour modeliser un role dans un protocole de cooperation metier via un processus metier 
abstrait : par exemple, dans les chapitres consacres aux etudes de cas en fin d'ouvrage, le client et 
l'agence de voyages jouent deux roles differents ; 

• soit pour definir un processus metier executable : le langage specifie un format d' execution 
portable pour des processus metier qui s'appuient exclusivement sur des services Web et des 
donnees au format XML. 

Le processus metier abstrait permet done de modeliser et d'exposer F interface publique d'un proto- 
cole de cooperation metier. Ce mode d' utilisation de BPEL4WS insiste plutot sur les aspects chore - 
graphiques du processus metier : definition des messages, ordonnancement des echanges, roles des 
participants. 

Le processus metier executable, obtenu par specialisation du modele abstrait, se focalise sur F imple- 
mentation privee propre a chacun de ses participants. La problematique d' implementation des traitements 
source ou cible des messages echanges, definis dans le modele abstrait, releve du domaine prive de 
chacune des entreprises concernees. 

Toutes les ressources externes, le processus lui-meme et les partenaires de ce processus sont modelises 
sous forme de services WSDL. 

A Finstar de la specification WSCL, BPEL4WS ne definit pas de quelle facon le processus metier 
sera deploye, ni quels seront les protocoles de communication ou les formats de message reellement 
mis en ceuvre au moment de l'execution. La specification BPEL4WS s'en tient a des representations 
de services WSDL abstraits. 

Syntaxe d'un descripteur de processus 

Le code suivant decrit la syntaxe generate d'une description de processus BPEL4WS : 

<process name="ncname" targetNamespace="uri " 
queryl_anguage="anyllRI"? 
expressionl_anguage="anyllRI"? 
suppressJoinFai1ure="yes | no"? 
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enableInstanceCompensation="yes | no" ? 

abstractProcess="yes | no"? 

xmlns=" http://schemas.xml soap.org/ws/2002/07/business-process/"> 
<partners>? 

<partner name="ncname" servicel_inkType="qname" 
myRole="ncname"? partnerRole="ncname"?>+ 

</partner> 
</partners> 
<containers>? 

<container name="ncname" messageType="qname"?> 

</container> 
</containers> 
<correlationSets>? 

<correlationSet name="ncname" properties="qname-l i st "/>+ 
</correlationSets> 
<faultHandlers>? 

<catch faul tName="qname"? faul tContainer="ncname"?>* 

activity 

</catch> 

<catchAll>? 
activity 

</catchAll> 
</faultHandlers> 
<compensationHandler>? 

activity 
</compensationHandler> 
activity 
</process> 

L'attribut queryLanguage definit FURI du langage de requete XML utilise pour la selection de nceuds 
lors de diverses operations (XPath 1 .0 par defaut). 

L'attribut expressionLanguage definit FURI du langage de requete XML utilise pour exprimer des 
expressions utilisees dans le processus (XPath 1.0 par defaut). 

L'attribut suppressJoinFailure precise si l'exception de jointure (joinFailure) est supprimee pour 
toutes les activites (acti vi ti es) du processus (no par defaut). 

L'attribut enablelnstanceCompensation precise si le processus peutetre compense en cas d'exception 
(no par defaut). 

L'attribut abstractProcess indique si le processus decrit est abstrait ou executable (no par defaut, 
c'est-a-dire executable). 

La collection des partenaires (partners) enumere les tiers qui interviennent durant le deroulement du 
processus. Ceux-ci sont modelises sous forme de services Web. 

La collection des conteneurs (containers) presente la liste des receptacles de donnees mis en ceuvre 
dans le processus, imperativement exprimes sous forme de messages WSDL. Ces conteneurs peuvent 
soit referencer des messages decrits dans des documents WSDL externes, soit directement integrer 
des descriptions de messages WSDL {Mining). Ces messages sont echanges avec les partenaires, 
mais les conteneurs peuvent aussi conserver des donnees internes necessaires au fonctionnement 
interne du processus. 
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La collection des ensembles de correlation (correl ationSets) est utilisee pour permettre les interac- 
tions asynchrones. 

La collection des gestionnaires d'exceptions (faultHandlers) fournit les activites a executer en cas 
d'erreurs dans le fonctionnement du processus. 

La collection des gestionnaires de compensations (compensati onHandl ers) decrit le code a executer en cas 
de compensation, c'est-a-dire lorsqu'il est necessaire d'annuler une action deja executee et terminee. 

Les activites (activities) represented les actions executees dans le cadre du processus metier 
modelise. Les types d' activites sont presentes dans le tableau ci-apres : 

Tableau des types d'activites BPEL4WS 



Activite Description 


receive 


Mise en attente d'un message d'un partenaire. 


reply 


Envoi d'un message de reponse a un message regu (par un receive) de la part d'un partenaire. 


invoke 


Envoi de message a sens unique ou d'une requete a un partenaire (invocation d'une operation definie dans 
I'interface WSDL du partenaire). 


assign 


Affectation de nouvelles valeurs aux donnees d'un conteneur (par copy). 


throw 


Generation d'une anomalie (f aul t). 


terminate 


Terminaison du processus. 


wait 


Mise en attente temporelle (sur un delai ou jusqu'a un instant donne). 


empty 


Activite vide (utile pour la synchronisation d'activites paralleles). 


sequence 


Bloc d'activites a executer en sequence. 


switch 


Selection d'une activite a executer parmi un ensemble. 


while 


Boucle d'execution d'une activite tant qu'une condition est verifiee. 


pick 


Attente bloquante d'un message d'un partenaire ou de I'expiration d'un delai. 


flow 


Bloc d'activites a executer en parallele. 


scope 


Definition d'une activite imbriquee a ses gestionnaires d'anomalie et de compensation. 


compensate 


Invocation d'une compensation sur une activite imbriquee (scope) qui a termine son execution normale- 
ment. 



Lien avec les specifications WS-Coordination et WS-Transaction 

La specification WS-Coordination decrit un framework extensible de construction de protocoles de coor- 
dination d' actions dans un environnement d' applications reparties (types de coordination). Les applica- 
tions sont capables de se coordonner entre elles via Futilisation d'un contexte de coordination gere sous 
le controle d'un service de coordination (coordinator) et de protocoles de coordination associes. 

La specification WS-Transaction decrit deux types particuliers de coordination : la transaction atomi- 
que AT (Atomic Transaction) et F activite metier BA (Business Activity). Le type de coordination 
pour la transaction atomique est utilise pour coordonner des activites de courte duree qui presentent 
une caracteristique de style « tout ou rien », sans etats intermediaries visibles. Le type de coordina- 
tion activite metier est utilise dans le cadre de la coordination de processus de longue duree, avec des 
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etats intermediaries visibles, qui necessitent la prise en compte et le traitement d' exceptions metier et 
l'accomplissement de taches de compensation. 

Ces deux specifications sont utilisees dans le cadre de la prise en charge de transactions metier et sont 
decrites chapitre 20, « Gestion des transactions ». Le chapitre 26 « Architecture en processus metier 
(BPEL) » presente une variante de F etude de cas dans laquelle la specification BPEL4WS est mise en 
ceuvre conjointement avec le type de coordination BA de WS-Transaction, via 1' implementation 
BPEL Orchestration Server de Collaxa. 

Implementations actuelles et a venir 

Dans l'immediat, des implementations de la specification BPEL4WS associee aux deux autres speci- 
fications (WS -Coordination et WS-Transaction) sont deja disponibles. 

Nous avons vu qu'immediatement apres la publication de la disponibilite de ces nouvelles specifica- 
tions, IBM a annonce, le 12 aout 2002, une implementation de reference de BPEL4WS nominee 
BPWS4J 1.0, telechargeable a partir du site dTBM alphaWorks (voir http://www.alphaworks.ibm.com/tech/ 
bpws4j). Une nouvelle version 1.1 corrective a ete publiee le 24 Janvier 2003. Cette implementation 
devaluation ne met pas en ceuvre les specifications WS -Coordination et WS-Transaction. En revan- 
che, elle comporte un plug-in Eclipse qui peut etre utilise pour creer et editer des scenarios BPEL. 

De meme, les dernieres versions du WSTK (Web Services Tool Kit), depuis la version 3.2.1, inte- 
grant des demonstrations de la mise en ceuvre de ces trois nouvelles specifications (voir http:// 
www.alphaworks.ibm.com/tech/webservicestoolkit). 

Enfin, IBM prevoit la prise en charge de BPEL4WS dans ses plates-formes de production WebSphere 
a partir de la version 5.0. En effet, l'annonce de la sortie de WebSphere Studio Application Developer 
Integration Edition 5.0 aux Etats-Unis (voir Software Announcement 203-034 du 4 fevrier 2003 : 
http://www.ibmlink.ibm. com/usalets&parms=H_203-034) precise que la prise en charge de cette specification 
dans Fenvironnement de developpement, ainsi que dans le serveur d' applications J2EE WebSphere 
Application Server Enterprise 5.0, devrait etre effective lors de la disponibilite des prochaines 
editions de ces versions (voir la section « Statement of Direction - Business Process Execution 
Language for Web services »). 

Le 17 fevrier 2003, l'annonce de disponibilite generale des produits a ete publiee (voir http:llwww- 
916.ibm.com/press/prnews.nsf/jan/F56124BC7EE0413685256CD000540B0F). Ceux-ci sont disponibles depuis 
le 21 fevrier. Les ressources pour le moteur d'execution WebSphere Application Server Enter- 
prise 5.0 sont accessibles a http://www-3.ibm.com/software/webservers/appserv/enterprise. Celles de 
WebSphere Studio Application Developer Integration Edition 5.0 peuvent etre atteintes a http://www- 
3Jbm.com/software/ad/studiointegration. 

Microsoft, de son cote, a annonce un nouveau projet nomme Jupiter lors de la conference MEC 2002 
(Microsoft Exchange Conference) qui s'est tenue a Anaheim en Californie du 7 au 11 octobre 2002 
(voir annonce : http://www.microsoft.com/presspass/press/2002/oct02/10-08jupiterpr.asp). Le projet devrait 
s'etaler sur dix-huit mois pour offrir deux versions du produit final. Lobjectif consiste a refondre et 
a integrer la gamme des serveurs e-business actuels de Microsoft (BizTalk Server, Content Manage- 
ment Server et Commerce Server). Cette refondation sous forme de composants (componentization) 
s'accompagnera de 1' incorporation de nouvelles fonctionnalites dont une gestion des processus 
metier qualifiee de « revolutionnaire », une meilleure prise en compte des technologies des services 
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Web XML et de BPEL4WS en particulier, et enfin, une meilleure assistance aux developpeurs et aux 
analystes metier via une integration superieure aux produits Visual Studio .NET et Office. 

La premiere version du produit final est prevue pour le deuxieme semestre 2003 et integrera les 
fonctions suivantes : 

• l'automatisation des processus, 

• le workflow, 

• les technologies d' integration, 

• la prise en charge de BPEL4WS, 

• l'assistance aux developpeurs. 

La version finale devrait sortir durant le premier semestre 2004. Elle ajoutera les caracteristiques 
suivantes a la version initiale : 

la gestion de contenu, 

les services de commerce, 

la gestion de catalogues, 

la gestion de campagnes, 

la gestion de sites, 

les outils d' analyse de sites, 

le ciblage de clientele, 

la personnalisation, 

l'assistance aux analystes metier. 

Quant a BEA, le troisieme auteur de BPEL4WS, WS -Coordination et WS-Transaction, la societe n'a 
annonce aucune prise en charge de ces specifications dans la version actuelle de son serveur d' appli- 
cations J2EE (WebLogic 7.0 et 8. 1). En revanche, selon une annonce effectuee par BEA le 13 decem- 
bre 2002, la prochaine plate-forme (nom de code « Gibraltar ») devrait les integrer, aussi bien dans le 
serveur d' applications que dans l'environnement de developpement Workshop (de meme que la prise 
en charge du SDK J2EE 1.4). 

II faut egalement signaler le produit BPEL Orchestration Server 2.0 de Collaxa (voir http:// 
www.collaxa.com) qui implemente les specifications BPEL4WS, WS -Coordination et WS-Transac- 
tion. Ce produit est le plus avance a l'heure de la redaction de ces lignes et pourrait bien constituer 
l'une des toutes premieres implementations commerciales disponibles. II est toujours en phase de 
mise au point en mars 2003 et la version beta 5 est annoncee. Ce serveur utilise la technologie 
J2EE nativement et peut done acceder a toutes les ressources de cette plate-forme : services Web, 
files d'attente JMS, e-mails, connecteurs JCA, pages JSP... Les scenarios metier sont decrits sous 
la forme de fichiers .jbpel qui font appel a une metaphore similaire a celle des pages JSP. Ces 
fichiers sont en realite des classes Java annotees (metadonnees codees selon une syntaxe de type 
XDoclet : voir http://xdoclet.sourceforge.nef) qui, apres compilation, se transforment en classes Java 
executables par la JVM. La version beta 5 introduit egalement la prise en charge directe des scenarios 
XML (fichiers d'extension .bpel). 
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La societe Momentum Software (voir http://www.momentumsoftware.com), etablie a Austin (Texas), 
dispose egalement d'une implementation de BPEL4WS operationnelle sur la plate-forme .NET : 
ChoreoServer for .NET (voir http://www.momentumsoftware.com/images/ChoreoServer.pdf). Ce produit est 
destine aux editeurs independants (ISV) et aux revendeurs. Une version equivalente, portee sur la 
plate-forme J2EE, devrait apparaitre courant 2003. 

Choreology (voir http://www.choreology.com), editeur du produit Cohesions 1.0 qui implemente la speci- 
fication BTP de l'OASIS, a annonce le 14 aout 2002 la prise en charge future des specifications 
BPEL4WS, WS -Coordination et WS-Transaction par son produit Cohesions (voir http://www.choreo- 
logy. com/news/1 40802_ webservices. html) . 

La societe Vergil Technology prevoit egalement F integration de la specification BPEL4WS dans son 
produit Web Services Orchestration Suite (voir http://www.vergiltech.com/vorchestration.htm). 

A l'heure de la redaction de cet ouvrage, certains signes laissent a penser que les initiateurs de 
BPEL4WS travaillent a la publication d'une evolution de la specification initiale. C'est vraisembla- 
blement cette nouvelle version qui devrait etre soumise a un organisme de standardisation (W3C ou 
OASIS ?) durant l'annee 2003. 



BPML 



La specification BPML (Business Process Modeling Language) est un metalangage de modelisation 
des processus metier dont le but est de fournir un modele d'execution pour les processus metier colla- 
boratifs et transactionnels. 

Cette specification est menee par l'organisation BPMI (Business Process Management Initiative, voir 
http://www.bpmi.org) dont l'objectif est de standardiser la gestion des processus metier qui recouvrent de 
multiples applications et partenaires metier en intranet et sur Internet. Par rapport a ebXML, cette 
organisation se presente comme celle qui standardise F implementation des processus metier alors 
qu'ebXML standardise les interfaces publiques de ces processus. 

Cette organisation a ete creee en aout 2000 sous Fimpulsion de la societe Intalio (http://www.intalio.com) 
par Aventail, Black Pearl, Blaze Software, Bowstreet, Cap Gemini Ernst & Young, Computer Sciences 
Corporation, Cyclone Commerce, DataChannel, Entricom, Ontology. Org, SI Corporation, Versata, 
VerticalNet, Verve, et XMLFund (voir annonce : http://www.intalio.com/news/releases/20000807.html). 

La version de travail initiale de la specification a ete publiee le 8 mars 2001. La version 1.0 a ete vali- 
dee et rendue publique le 26 juin 2002, apres sept revisions de la version initiale (voir annonce : http:/ 
/www.intalio.com/news/releases/20020626BPML.html). Celle -ci est disponible a Padresse http://www.bpmi.org/ 
specifications. esp. 

La specification BPML est completee par la specification BPQL (Business Process Query Language). 

BPML est maintenant pris en charge par plus de cent quatre-vingt membres dont BEA Systems, 
IONA Technologies, IBM, Hewlett-Packard, Hog, SAP, SilverStream, SUN Microsystems, Sybase, 
TIBCO, WebGain. Les entreprises qui soutiennent Finitiative BPMI proviennent de tous les horizons, 
que ce soit du monde du workflow, de FEDI, du B2B ou de FEAI. 

Schematiquement, BPML divise un processus metier en trois parties : 

• une interface publique de description du processus ; 

• deux implementations privees, propres a chacun des deux partenaires concernes. 
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Figure 21-2 

Interface publique et implementations privies BPML. 



L' interface publique est done commune aux partenaires et peut etre prise en charge par des protocoles 
tels qu'ebXML, BizTalk, RosettaNet ou WSDL. 

Les implementations privees peuvent reposer sur differentes specifications, comme BPML ou 
XLANG par exemple. 

La specification BPML definit son propre espace de noms, prefixe par bpml . Elle fait egalement appel 
a des elements des specifications WSCI, WSDL et XML Schema, dont elle reference les espaces de 
noms et elle s'appuie egalement sur les specifications XPath et XQuery. 

La specification est implemented dans le serveur n3 d'Intalio qui se definit comme le premier Business 
Process Management System (voir http://www.intalio.com/products/server/index.html). La societe Infosys 
Technologies a egalement developpe un moteur BPML de demonstration : Choreo (voir http://www.info- 
sys.com/consulting/choreo.asp). La societe Computer Sciences Corporation (voir http://www.csc.com) a 
annonce le 22 juillet 2002 qu'elle retenait la specification BPML 1.0 comme element de fondation de 
son architecture d'entreprise BPM e3 (voir annonce : http://www.csc.com/newsandevents/news/1801.shtml), 
reference de Farchitecture e3 : http://uk.country.csc.eom/en/kl/9.shtml). Le produit Integrator de Sterling 
Commerce incorpore aussi une implementation de la specification BPML, en plus du framework 
ebXML Messaging Service 2.0 (voir http://www.sterlingcommerce.com/solutions/products/ebi/integrator/inte- 
grator.html). 

Outre la specification BPML, les societes Popkin Software (http://www.popkin.com), Casewise (http:// 
www.casewise.com) et Computer Sciences Corporation (http://www.csc.com) ont decide, le 28 aout 2002, 
de constituer un groupe de travail au sein de l'initiative BPMI dont l'objectif est de produire la speci- 
fication d'une notation standard dans le domaine de la gestion des processus metier (voir annonce : 
http://www.popkin.com/newsandevents/press_releases/archive/8_28_2001.htmi). Cette notation standard, 
nommee BPMN (Business Process Modeling Notation), constituera une notation graphique de 
BPML et pourra etre utilisee dans des logiciels d'analyse, de conception et de description de proces- 
sus metier. 



Gestion des processus metier 

Chapitre 21 

L' initiative BPMI, a travers la specification BPML couplee a WSCI, BPQL et BPMN, vise a couvrir 
l'ensemble du spectre du cycle de vie d'un processus metier : de la modelisation a l'execution sur la 
plate-forme finale. Celle-ci, outre le support de Sun Microsystems, semble rencontrer un certain 
succes aupres d'acteurs importants tels que Computer Sciences Corporation ou Sterling Commerce. 



WSCI 



WSCI est une specification proposee par BEA, Intalio, SAP et Sun Microsystems pour prendre en 
compte la collaboration d' application a application. La specification BPML s'appuie sur WSCI (voir 
le tableau des espaces de noms de BPML). La specification WSCI a ete soumise au W3C sous forme 
d'une note datee du 8 aout 2002 (voir http://www.w3.org/TR/wsci). Elle constitue la ressource principale, 
conjointement avec WSDL 1.2, pour les travaux du groupe de travail Web Services Choreography du 
W3C, cree en Janvier 2003. 

WSCI definit un langage de description des echanges collaboratifs entre services Web. Cette speci- 
fication concerne essentiellement les aspects lies a la choregraphie des echanges. En revanche, elle 
ne traite pas les questions d' orchestration des processus metier. Elle ne decrit que le comportement 
du service que Ton peut observer de l'exterieur, ainsi que les regies d'interaction entre le service 
et son environnement. 

Pour son propre fonctionnement, WSCI s'appuie sur les langages de description de services Web, et 
plus particulierement sur WSDL 1.1. 

La specification WSCI definit son propre espace de noms, prefixe par wsci . Elle fait egalement appel 
a des elements des specifications WSDL et XML Schema, dont elle reference les espaces de noms, 
ainsi qu'a la specification XPath. 

La specification WSCI est extensible : les extensions realisees peuvent soit etendre la semantique origi- 
nelle de WSCI, soit etendre F interface et les definitions du modele sans en modifier la semantique. 

Le concept principal de WSCI est Finterface. Chacun des participants d'un processus metier doit definir 
son interface WSCI, c'est-a-dire le comportement de son service en termes de messages echanges avec 
les autres participants dans le cadre du deroulement du scenario associe au processus metier. Le 
comportement est exprime par des dependances temporelles et logiques entre les messages echanges. 
Un service Web peut exposer plusieurs interfaces qui prennent en charge differents scenarios. 

Les messages echanges entre participants sont emis et/ou recus par des activites. Ces activites sont 
soit atomiques, soit complexes. Dans ce dernier cas, elles sont composees, par recursivite, d' autres 
activites. Dans le cadre d'une liaison avec une description de service WSDL, une activite atomique 
qui traite un message correspond a l'execution d'une operation. Les activites WSCI peuvent etre 
executees en sequence, en parallele, en boucle (structures de type for-each, while et repeat-until) 
ou conditionnees par revaluation d'expressions logiques ou l'occurrence d'un evenement. 

L unite de base reutilisable d'une description WSCI est le processus qui definit une partie du compor- 
tement observe. Un processus est instancie : 

• suite a la reception d'un ou plusieurs messages definis comme elements declencheurs ; 

• sur appel externe du processus (visible de 1' interface) ; 

• sur appel interne du processus par 1' implementation du service (invisible de Finterface). 
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Les processus peuvent etre definis et references soit au niveau de 1' interface (processus « racines »), 
soit dans des activites complexes (processus « imbriques »). 

Chaque activite est definie et executee dans le cadre d'un et un seul contexte d' execution. Ce contexte 
comprend un ensemble de declarations accessibles a toutes les activites qui lui sont liees, une defini- 
tion des evenements exceptionnels et des comportements associes susceptibles de se produire durant 
l'execution des activites et enfin les proprietes transactionnelles attachees au deroulement des activi- 
tes. Ces contextes d' execution peuvent etre imbriques : dans ce cas, la portee d'un contexte donne est 
limitee a son propre niveau et a celui de ses parents jusqu'a la racine par recursivite. 

La specification decrit egalement le concept de correlation de messages, c'est-a-dire la maniere dont 
la consistance semantique des conversations dans lesquelles participe un service Web est maintenue. 
WSCI ne specifie pas la maniere d'implementer la correlation mais foumit le moyen de la modeliser 
et de l'exposer. 

La declaration de comportements exceptionnels est pre vue et peut etre definie au niveau d'un 
contexte d'execution. Ces comportements peuvent survenir lors de la reception d'un message parti- 
culier, ou du fait de la levee d'une exception generee par 1' implementation du service ou la reception 
d'un message d'erreur WSDL (Fault), ou bien encore suite au declenchement d'un timeout. Diffe- 
rents mecanismes de gestion de ces exceptions sont prevus selon le niveau du contexte d'execution, 
y compris la possibilite de les recuperer (recoverable exceptions), c'est-a-dire de gerer une situation 
de defaillance partielle d'un processus. 

La gestion de comportements transactionnels est egalement possible, via l'association d'un contexte 
a une transaction. La transaction peut declarer des activites de compensation qui ne seront executees 
qu'en cas de succes de la transaction et de necessite de la defaire (echec de l'un des services Web 
participants). Une transaction peut etre soit atomique, soit imbriquee. Une transaction atomique ne 
peut etre decomposee en sous-transactions, alors qu'une transaction imbriquee peut etre decomposee 
en sous-transactions atomiques et/ou a nouveau imbriquees et ainsi de suite... En cas d'annulation 
d'une transaction imbriquee (rollback), les sous-transactions ouvertes courantes sont tout d'abord 
annulees (de maniere recursive), puis les sous-transactions terminees avec succes sont compensees 
dans l'ordre inverse de terminaison. 

WSCI definit par ailleurs la notion de modele global. A l'instar d'une conversation WSCL (voir 
section suivante), une interface WSCI exprime les echanges de messages du point de vue d'un seul 
participant. Le modele global permet de decrire une vue multiparticipant de l'ensemble des echanges 
de messages. Ce modele est represente par une collection d'interfaces des services participants et une 
collection de liens entre les operations de ces services (sources et destinations de messages) definies 
par un langage de description de services tel que WSDL. 

La specification WSCI prevoit egalement la possibilite de realiser des interactions avec des services 
Web dont les caracteristiques d'acces ne sont connues qu'au moment de l'execution (points d'acces). 
Ceci est possible a travers la mise en ceuvre du concept de participation dynamique. Cette caracteris- 
tique autorise ainsi 1' usage de systemes de recherche et de decouverte de services Web tels que les 
annuaires UDDI, par exemple. 

Enfin, en complement du document de la specification, il faut signaler l'existence d'un editeur 
d'interfaces WSCI developpe par Sun Microsystems : le Sun ONE WSCI Editor (voir http:// 
wwws.sun.com/software/xml/developers/wsci/download). 
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WSCL 



La specification WSCL a ete proposee en mai 2001 par une equipe de Hewlett-Packard (voir http:// 
xml.coverpages.org/HP-WSCL10-200105.pdf). Elle a ete adressee au W3C le 4 fevrier 2002, et enregistree 
sous forme d'une note datee du 14 mars 2002 (voir http://www.w3.org/TR/wscl10). 

La specification avait ete precedee par la publication, debut 2001, de CDL (Conversation Definition 
Language), un format de description de conversations metier sous forme de schemas XML, issu de 
l'architecture e-Speak. Cette specification initiale a constitue l'un des documents presentes (voir http:/ 
/www.w3.org/2001/03/WSWS-popa/paper20) lors de F atelier Workshop on Web services organise par le 
W3C, les 11 et 12 avril 2001 a San Jose en Californie, et representatifs de la position de Hewlett- 
Packard sur les sujets a prendre en compte par le W3C pour ses actions futures dans le domaine de la 
normalisation des services Web. 

Le document Service Framework Specification, Part I - Version 2.0 de l'architecture e-Speak (voir 
http://www.hpl.hp.com/techreports/2001/HPL-2001-138.pdf), publie le 7 juin 2001, illustre parfaitement le 
degre d'avancement des reflexions de Hewlett-Packard dans le domaine des technologies de services 
Web, acquis avant 1' apparition des specifications SOAP, WSDL et UDDI. Ce document montre 
notamment la position de CDL dans l'architecture e-Speak et permet de mieux comprendre son 
origine. 

Conversations 

La specification WSCL offre un moyen de decrire des interfaces abstraites de services Web. Plus 
precisement, le langage specifie : 

• les « conversations » de niveau metier ; 

• les processus pris en charge par les services Web. 

Les descriptions de conversations sont des documents XML qui specifient les messages echanges 
(eux-memes sous forme de documents XML), ainsi que l'enchainement des echanges. 

Cette specification doit s'utiliser conjointement avec d'autres langages de description de services tels 
que WSDL. Son objectif est de fournir le moyen de decrire le comportement dynamique d'un service 
Web en s'appuyant sur sa definition d'interface statique, a travers une modelisation des sequences 
d' interactions et d'operations valides pour cette interface. Ces modeles peuvent etre ensuite exploites 
par des systemes de gestion de processus metier ou de workflows pour les combiner avec d'autres 
modeles de conversations : c'est ce que Ton definit sous les vocables d' orchestration ou de choregraphie 
de services Web. 

WSCL permet done de specifier quels sont les documents XML echanges avec le service Web, ainsi 
que les sequences d'echanges de ces documents. Les conversations ainsi definies sont elles-memes 
exprimees sous la forme de documents XML qui peuvent ensuite aisement etre exploites par des 
systemes d'infrastructure de services Web, de meme que par des outils de developpement appropries. 

Structures du langage 

Les principaux elements definis par la specification WSCL sont les suivants : 

• les descriptions de types de documents (Document Type Descriptions) : elles precisent les types de 
documents XML (schemas) qu'un service peut emettre ou recevoir durant une conversation ; 
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• les interactions (Interactions) : celles-ci modelisent les actions d'une conversation sous la forme 
d'echanges de documents XML entre les divers participants a cette conversation ; 

• les transitions (Transitions): elles explicitent l'ordonnancement des interactions. La relation 
d'ordonnancement est decrite par Finteraction source, Finteraction cible, eventuellement associees 
au type de document transporte de la source a la cible ; 

• la conversation (Conversation) : elle enumere les interactions et transactions qui en sont les 
constituants. 

Les modeles d' interaction pris en charge par une conversation WSCL sont : 

• remission (Send) : le service Web envoie un document a destination d'un autre participant ; 

• la reception (Recei ve) : le service Web recoit un document en provenance d'un autre participant ; 

• remission-reception (SendReceive) : le service Web envoie un document a destination d'un autre 
participant et s' attend a recevoir un document en re tour ; 

• la reception-emission (Recei veSend) : le service Web recoit un document en provenance d'un autre 
participant et renvoie un document en retour ; 

• Finteraction vide (Empty) : celle-ci ne met en ceuvre aucun echange de documents. Son unique role 
consiste a decrire le debut et la fin d'une conversation. 

Une conversation est similaire a une interface publique, a la maniere d'une interface WSDL, ou 
encore d'une description IDL Corba ou d'une classe interface dans un langage oriente objet tel que 
Java ou C#. Cependant, la faculte d' expression d'une conversation est superieure car elle publie 
egalement l'ordonnancement possible des operations decrites par l'interface. 



La conversation du point de vue d'un des participants 

II faut ici remarquer que la definition d'une conversation exprime celle-ci du point de vue d'un seul des participants. 
Cette definition se place generalement dans la perspective du fournisseur du service Web et debute ainsi par une 
interaction de type reception ou reception-emission. Le modele de la conversation peut etre reexprime du point de 
vue du consommateur du service Web. 



Les documents pris en charge sont decrits uniquement par des schemas XML. La direction prise par 
rapport a l'interaction (document entrant ou sortant) est precisee par le nom de F element : un docu- 
ment entrant est modelise par une etiquette InboundXMLDocument, tandis qu'un document sortant est 
specifie par F etiquette OutboundXMLDocument. 



Utilisation des schemas 

A la difference de WSDL, la specification WSCL n'incorpore pas les schemas XML qui sont utilises pour prendre 
en charge les echanges durant la conversation (Business Payload). La specification des schemas XML est dele- 
guee a des organismes differents, independants, responsables de la standardisation et de la normalisation de ces 
schemas dans divers secteurs economiques, industriels ou sociaux (horizontaux ou verticaux). WSCL se contente 
de referencer les schemas mis en ceuvre dans la conversation (comme WSDL lorsque seule la balise import est 
utilisee). 
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La structure generate d'une conversation se presente comme suit : 

<?xml version="1.0" encoding="UTF-8"?> 

Conversation name="NomDeLaConversation" initial Interaction="Debut" final Interaction="Fin" > 
<ConversationInteractions> 

interaction ... /> 

<Interaction ... /> 

</ConversationInteractions> 
<ConversationTransitions> 

<Transition ... /> 

transition ... /> 

</ConversationTransitions> 
</Conversation> 

Les interactions decrivent les echanges unitaires et les transitions represented les branches du graphe 
qui lient les interactions entre elles pour donner le protocole de conversation. Une conversation porte 
obligatoirement les attributs : 

• name : le nom de la conversation specifiee (URI) ; 

• initial Interaction : F interaction qui declenche la conversation ; 

• final Interact! on : l'interaction par laquelle se termine la conversation. 

La conversation definit ensuite deux collections d'elements : la collection des interactions (Conversation- 
Interactions) et la collection des transitions (ConversationTransitions). 

Combiner WSCL et WSDL 

La specification WSCL precise les formats de messages echanges (payload) ainsi que Fordre dans 
lequel sont realises ces echanges. Elle ne specifie rien en ce qui concerne les protocoles de communi- 
cation mis en ceuvre pour realiser ces transferts de documents. Elle indique simplement que la liaison 
a un protocole de communication est soit determinee par l'utilisation d'un framework particulier qui 
prend en charge 1' implementation de la conversation, soit par l'usage d'un langage de description de 
liaison specifique tel que WSDL par exemple. 

Les specifications WSCL et WSDL sont en effet complementaires. Le tableau suivant synthetise la 
correspondance des concepts manipules par les deux specifications. 

Correspondances semantiques entre WSDL et WSCL 



Concepts 


WSDL 


WSCL 


Interfaces Choregraphie 


Hors du champ de la specification 


Transition 


abstrai,es Messages 


Operation 


Interaction 


Liaisons protocolaires 


Liaison 


Hors du champ de la specification 


Services concrets 


Service 


Hors du champ de la specification 
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Ce tableau de correspondances, issu du document de la specification WSCL, illustre parfaitement 
la complementarite qui existe entre les deux specifications. Le concept charniere est celui de 
message, element constitutif des interfaces abstraites de services Web. C'est le message (via 
l'operation pour WSDL et l'interaction pour WSCL) qui permet d'etablir le lien entre les deux 
specifications et d'accroitre ainsi, par cette combinaison, la puissance d'expression de WSCL et 
WSDL. Lexpression statique de l'interface publique d'un service Web, decrite au format WSDL, 
se trouve renforcee via la dimension dynamique introduite par les regies choregraphiques mode- 
lisees en format WSCL. 

La correspondance des concepts entre les deux specifications est egalement prolongee, dans une 
certaine mesure, par une correspondance entre les elements de syntaxes des deux langages. 

Correspondances syntaxiques entre WSDL etWSCL 



WSDL WSCL 


Port Type 


Conversation 


Operation : 

- One-way 

- Request-response 

- Sol icit-response 

- Notification 


Interaction : 

- Receive 

- ReceiveSend 

- SendReceive 

- Send 


Input 


InboundXMLDocument 


Output, Fault 


OutboundXMLDocument 


Message (types de donnees incorpores) 


Attributs href Schema (types de donnees references) 



Une fois etablies ces correspondances, comment aller plus loin et combiner ces deux specifications 
pour introduire une continuite entre la description de la conversation (WSCL) et la mise en ceuvre des 
protocoles de communication susceptibles de permettre les echanges de documents (WSDL) ? 

La specification WSCL propose trois alternatives possibles : 

• une mise en correspondance des elements de la conversation decrite en WSCL avec les elements 
descriptifs des liaisons aux protocoles utilises dans la description WSDL ; 

• l'ajout d'elements de choregraphie a une description de type de port WSDL. Ceux-ci sont ajoutes 
dans un document WSCL additionnel qui ne contient que la collection des transitions. Une mise en 
correlation est ensuite realisee entre Fattribut d'operation de type de port WSDL nom et l'attribut 
WSCL href des sous-elements Sourcelnteraction et Destinationlnteraction. L element Source- 
InteractionCondition reference, quant a lui, un message output ou fault de l'operation WSDL 
correspondante ; 

• une mise en correspondance des elements de la conversation WSCL avec les messages des operations 
equivalentes dans un type de port. 
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WSFL 



La specification WSFL a ete proposee en mai 2001 par une equipe d'IBM (voir http://www-3.ibm.com/ 
software/solutions/webservices/pdf/WSFL.pdf). Cette specification definit un langage de description de 
compositions de services Web. Plus precisement, le langage specifie deux modeles de conception 
{patterns) : 

• le pattern usage d'un ensemble de services Web dont le resultat decrit un processus metier (modele 
de flux) ; 

• le pattern interaction d'un ensemble de services Web dont le resultat decrit les interactions entre 
entites metier (modele global). 

Cette specification s'appuie sur la specification WSDL. Le document est present, depuis la 
version 2.3, dans le Web Services Tool Kit publie sur le site d'IBM alphaWorks. 

La specification WSFL considere que toutes les activites qui participent a un processus metier sont 
des services Web. Elle definit un langage XML de description de compositions de services Web : 
toute composition de services Web, qu'il s'agisse d'un modele de flux ou d'un modele global, peut 
devenir a son tour, par recurrence, un composant d'une nouvelle composition de services Web. 

Grace a cette recursivite, la conception de processus metier peut etre abordee sous deux angles : soit 
par une approche bottom-up qui, par agregations et abstractions successives, permet de modeliser le 
processus complet, soit par F approche top-down qui, via des raffinements successifs, assure la 
decomposition du processus modelise en services Web unitaires agreges. 

Du fait de la publication recente de la specification BPEL4WS, appelee a remplacer la specification 
WSFL d'IBM, ainsi que la specification XLANG de Microsoft, nous n'entrerons pas plus avant dans 
les details de cette specification. 



XLANG 



Microsoft dispose deja de sa propre implementation d'un langage de specification de l'automatisa- 
tion des processus metier fondes sur des services Web. Ce langage, nomme XLANG (prononcer 
« slang »), est deja implements dans le serveur BizTalk disponible depuis debut 2001 (voir http:// 
www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm). II prend egalement appui sur la specification 
WSDL (voir specification BizTalk Framework 2.0: Document and Message Specification a l'adresse 
http://www. microsoft. com/bizta!k/techinfo/framwork20.asp) . 

XLANG definit un langage de description du comportement individuel d'un service Web qui parti- 
cipe a un processus metier. II decrit egalement comment combiner de tels services Web pour produire 
un processus metier multiparticipant. 

Plus particulierement, XLANG s' attache a prendre en compte les fonctionnalites suivantes : 

la construction de flux de controle sequentiels et paralleles, 

les transactions longues avec compensation, 

la correlation de messages, 

la gestion des exceptions de traitement internes et externes, 

la description de comportement modulaires, 
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• la reference de service dynamique, 

• les contrats multiroles. 

La specification XLANG definit son propre espace de noms, dont le prefixe xl ang est associe a FURI 
http://schemas.microsoft.com/biztalk/xlang/. Par ailleurs, elle fait appel aux specifications WSDL (prefixe 
wsdl, associe a FURI http://schemas.xmlsoap.org/wsdl/) et XML Schema (prefixe xs, associe a l'URI http:/ 
/www. w3. org/200 1/XMLSchema) . 

De meme que pour la specification WSFL, du fait de la publication recente de la specification 
BPEL4WS, appelee a remplacer cette specification, ainsi que la specification WSFL d'IBM, nous ne 
decrirons pas plus en detail cette specification. 

Vers une entreprise toujours plus etendue 

Lapparition d'XML et le developpement des technologies liees aux services Web vont a terme chan- 
ger profondement le marche des logiciels de workflow et des systemes d'EAI. Lautomation des 
processus metier interentreprises etait realisee via Futilisation de logiciels ou progiciels proprietaries 
souvent onereux et necessitant des adaptations plus ou moins importantes suivant le contexte. La 
principale difficulte, dans ces environnements orientes traitements, residait dans le fait que l'imple- 
mentation interne de ces logiciels n'etait generalement pas explicitement separee de la description 
des protocoles extemes mis en ceuvre dans les echanges. Cette difficulte s'accroissait egalement en 
raison de la nature heterogene des donnees echangees par ces traitements : informations proprietai- 
res, incompatibles entre elles, donnees en provenance des systemes applicatifs patrimoniaux (legacy 
systems) non documentees, formats des donnees incompatibles... 

Par ailleurs, Finstallation de tels systemes d'integration laissait souvent de larges parts du systeme 
d'information dans Fombre, du fait des difficultes d'interaction entre systemes heterogenes proprie- 
taires. C'est notamment pour cette raison que les editeurs de logiciels d'EAI etaient contraints de 
developper de nombreux connecteurs ou adaptateurs afin de permettre a leurs plates-formes respecti- 
ves de communiquer, de maniere bilaterale, avec les principaux logiciels ou ERP du marche. C'est 
egalement pour cette raison que la communaute Java a decide de promouvoir F architecture JCA 
(Java Connector Architecture) afin de diminuer les couts d'integration des systemes d'information. 

Cependant, le deplacement des marches vers Internet, la necessite accrue de communication entre les 
systemes d'information des acteurs economiques a travers les pare-feu, la necessite de desenclaver 
ces merries systemes d'information, le besoin de standardiser les formats de donnees echangees entre 
plates-formes integrees ont fini par rencontrer, dans F emergence des technologies des services Web, 
le support adequat a une nouvelle evolution de Fentreprise ouverte : il s'agit maintenant de rendre les 
systemes d'information des partenaires economiques interoperables a travers F interaction de leurs 
applications via Internet (IAI). 

Les technologies des services Web permettent d' organiser des processus metier interentreprises, tout 
en respectant les imperatifs premiers d'independance et de securite des systemes d'information de 
chacune des entreprises qui collaborent a ce processus. Cette faculte d'extension du champ de Fauto- 
matisation des processus metier en direction de systemes d'information interconnectes via Internet 
est entierement due a la banalisation du langage XML, maintenant integre dans tous les composants 
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des architectures logicielles : systemes d'exploitation, bases de donnees, applications, environnements 
de developpement, navigateurs... 

L'examen des principales specifications en lice, candidates au statut de futur standard dans le domaine 
de la gestion des processus metier, a mis aussi en evidence le role pivot que la specification WSDL 
jouera egalement dans ce domaine. En effet, pratiquement toutes les specifications s'appuient sur des 
descriptions de services Web au format WSDL. Certaines de ces specifications prevoient meme l'expo- 
sition du processus metier modelise sous forme d'un document WSDL (BPEL4WS, par exemple). 

Avec la mise au point d'un standard de gestion des processus metier, commencent enfin a apparaitre 
les outils technologiques et methodologiques qui permettront de mettre au point les logiciels et les 
infrastructures necessaires pour atteindre ce que James Snell d'IBM appelle « le Web transaction- 
nel », c'est-a-dire « une architecture du Web organisee de facon a echanger des informations entre 
applications de maniere intelligente ». 

Sites de reference et ressources 

Dans le domaine de la gestion de processus metier, les ressources et references sont deja tres 
nombreuses du fait qu'il s'agit la d'un sujet qui est traite depuis plusieurs annees. Nous avons 
regroupe ici des elements d' information qui traitent de cette question d'un point de vue en rapport 
avec l'approche proposee par les technologies de services Web. Bien entendu, les produits cites, pour 
la plupart, n'implementent pas encore les dernieres specifications que nous venons d'evoquer. 
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Workflow Patterns, Eindhoven University of Technology/Department of Technology Management : 
httpMmitwww. tm. tue. nl/research/patterns 

A new model for ebXML BPSS Multi-party Collaborations and Web Services Choreography, Jean- 
Jacques Dubray : http://www.ebpml.org/ebpml.doc 

A Novel Approach for Modeling Business Process Definitions, Jean-Jacques Dubray : http:// 
www. ebpmi. org/ebpm!2.2. doc 
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1 06. ibm. com/developerworks/iibrary/ws-autobp 
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Using Model-Driven Architecture to Develop Web Services, IONA White Paper, April 2002 : http:/ 
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Scenarios d'architectures - 
Implementation des clients 



Ce chapitre est le premier de la section consacree aux etudes de cas. Plutot que de presenter diffeientes situa- 
tions qui n'ont pas de liens entre elles, nous avons choisi de ne presenter qu'une seule etude fonctionnelle, 
autour de laquelle nous allons pouvoir montrer differentes approches d' architecture et d' implementation. 

Cette section est organisee de la maniere suivante : 

• Chapitre 22 : ce chapitre introduit la problematique fonctionnelle qui constituera la trame sous- 
jacente des chapitres suivants. Chacune des variations autour du cas initial y sont decrites. Cette 
description fonctionnelle est accompagnee de la presentation de F implementation du client qui 
sera utilisee pour toutes les variantes de 1' architecture et de 1' implementation des serveurs. 

• Chapitre 23 : il illustre une premiere forme d' architecture statique dans laquelle la partie serveur 
est exclusivement implementee en Java et en mode synchrone. Cette premiere realisation est 
destinee a illustrer de maniere didactique, de la conception jusqu'au deploiement, le developpement 
d'un nouveau service Web et sa mise en ceuvre dans un environnement simple. 

• Chapitre 24 : il s'agit cette fois d'une architecture dynamique qui s'appuie sur la technologie 
UDDI dans laquelle la partie serveur est toujours implementee en Java et en mode synchrone. 

• Chapitre 25 : F architecture est toujours dynamique et fait egalement appel a la technologie UDDI mais 
une partie de F implementation, toujours en mode synchrone, est realisee a Faide du framework .NET. 

• Chapitre 26 : ce dernier chapitre de la section presente une autre implementation du meme service, 
dans une architecture statique, en mode asynchrone, et exprimee sous forme de processus metier 
en technologie BPEL4WS. 

Les differents chapitres consacres aux etudes de cas sont ainsi plutot organises autour d'un scenario 
evolutif en termes de fonctionnalites et de complexite. II est done conseille, pour une meilleure 
comprehension, de lire ces chapitres dans l'ordre. 
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La description des produits utilises et les modalites de parametrage correspondantes sont decrites ail 
debut des chapitres 23, 24, 25 et 26. Les installations de produits sont cumulatives d'un scenario a 
l'autre. Les modifications eventuelles des parametrages anterieurs ou des configurations (ajouts, 
retraits) sont signalees lorsque cela est necessaire. Le tableau ci-apres resume les caracteristiques des 
differents scenarios presentes dans les chapitres qui suivent : 



Tableau resume des caracteristiques des scenarios presentes 



N° scenario 


Caracteristique 


Description 


1 
(chapitre 23) 


Type d'architecture 


Statique 


Style d'echange 


RPC 


Style de codage 


Encoded 


Nombre d'agents logiciels 


5 (1 client + 4 serveurs SOAP) 


Specifications mise en ceuvre 


SOAP + WSDL 


Nombre d'implementations SOAP 


1 Java + 1 JavaScript 


Technologie cliente 


Windows 2000 Professional + IE 5.0 (et ulterieures) 


Technologie serveurs 


Java (implementation Windows) 


2 

(chapitre 24) 


Type d'architecture 


Dynamique 


Style d'echange 


RPC 


Style de codage 


Encoded 


Nombre d'agents logiciels 


10 (1 client + 8 serveurs SOAP + 1 serveur UDDI) 


Specifications mise en ceuvre 


SOAP + WSDL + UDDI 


Nombre d'implementations SOAP 


2 Java + 1 JavaScript 


Technologie cliente 


Windows 2000 Professional + IE 5.0 (et ulterieures) 


Technologie serveurs 


Java (implementation Windows) 


3 
(chapitre 25) 


Type d'architecture 


Dynamique 


Style d'echange 


RPC 


Style de codage 


Encoded 


Nombre d'agents logiciels 


10 (1 client + 8 serveurs SOAP + 1 serveur UDDI) 


Specifications mise en ceuvre 


SOAP + WSDL + UDDI 


Nombre d'implementations SOAP 


2 Java + 1 C# + 1 JavaScript 


Technologie cliente 


Windows 2000 Professional + IE 5.0 (et ulterieures) 


Technologie serveurs 


Java (implementation Windows) + .NET 


4 
(chapitre 26) 


Type d'architecture 


Statique 


Style d'echange 


Document 


Style de codage 


Litteral 


Nombre d'agents logiciels 


5 (1 client + 4 serveurs BPEL) 


Specifications mise en ceuvre 


SOAP + WSDL + BPEL4WS + WS-Transaction + WS-Coordination 


Nombre d'implementations SOAP 


1 Java + 1 JavaScript 


Technologie cliente 


Windows 2000 Professional + IE 5.0 (et ulterieures) 


Technologie serveurs 


Java (implementation Windows) 
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Scenario n°1 (architecture statique - implementation Java) 

Un nouveau service est propose par une agence de voyages souhaitant formaliser un processus de reser- 
vation de voyages qui existe deja sous forme partiellement automatisee, mais qui exige encore un 
certain nombre d'enchainements de taches manuelles de la part de ses employes. Les objectifs sont : 

• dans un premier temps, F automation des taches manuelles, actuellement executees par les 
employes de 1' agence, en interaction avec les sites Web de reservation des differents partenaires 
metier impliques dans le processus de reservation ; 

• dans un second temps, la mise a disposition d' un service Web de reservation de voyages a destination 
des clients finaux de F agence (prestataires de reservation, entreprises, etc.). 



Avertissement 

Le scenario presente ici n'est qu'un pretexte dont I'objectif consiste a montrer I'usage possible de nouvelles tech- 
nologies dans un cadre determine. Comme toujours dans ce type de situation, un tel exemple est loin d'etre repre- 
sentatif de la problematique metier du secteur economique auquel est « emprunte » le scenario envisage. Ce 
scenario est done implicitement simplificateur et, par construction, reducteur eu egard a la complexite des situations 
reelles rencontrees dans le domaine de la reservation de voyages. 



Systeme existant 

En premier lieu, la demarche consiste a analyser le systeme existant, a identifier les acteurs et les 
processus en cause, puis a definir et a concevoir le nouveau systeme de reservation en fonction des 
nouveaux objectifs. 

Acteurs 

Les differents acteurs concemes par le systeme d'information de F agence de voyages SW- Voyages 
sont essentiellement ses partenaires metier actuels. 

Ceux-ci, dans le cadre des differents accords de partenariat dans lesquels ils sont engages, ont pris la 
decision commune de proceder a des adaptations de leurs systemes d'information respectifs et 
notamment de rendre accessibles leurs systemes de back-office dans un contexte extranet, au moyen 
de la publication d'interfaces de services Web normalisees. 

L'agence de voyages : SW-Voyages 

L'activite de l'agence est essentiellement tournee vers la reservation de voyages aeriens, eventuelle- 
ment completee par des prestations de reservation de chambres d' hotels et/ou de vehicules automobiles 
sur le lieu de destination du client. 

La societe dispose de son propre site Internet, accessible par ses clients finaux a Fadresse http:// 
www.sw-voyages.com:8080. Ce site est principalement de nature institutionnelle et n'offre, a l'heure 
actuelle, aucun autre service a valeur ajoutee. 

La centrale de reservation aerienne : SW-Air 

Cette centrale de reservation constitue le partenaire principal de l'agence de voyages dans le processus 
global de son systeme de reservation. 
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Le service propose par SW- Voyages comporte imperativement une reservation aerienne (voyage en 
aller simple ou aller-retour) issue des disponibilites des compagnies aeriennes partenaires de SW-Air, 
et communiquees a SW- Voyages en fonction des caracteristiques du voyage souhaitees par le client. 

Les services de la centrale de reservation sont deja accessibles aux employes de SW- Voyages, a partir 
de Finterface Web du site extranet existant, lui-meme accessible a l'adresse http://www.sw-air.com:8080. 

Dans le cadre de ce partenariat, les deux societes ont convenu de rendre possible Faeces au systeme 
back-office de reservation de SW-Air, via une interface de service Web normalisee qui repose sur la 
specification WSDL. 

Ce second canal d'acces (service Web) s'ajoutera done au premier canal d'acces (site Web). Celui-ci 
restera inchange, hormis une adaptation pour brancher Finterface actuelle (IHM) sur la nouvelle 
interface de service Web du back-office. 

La centrale de reservation hoteliere : SW-H6tels 

En complement de sa prestation principale de reservation aerienne, et sur option du client, Fagence 
de voyages propose egalement une prestation de reservation hoteliere sur le lieu de destination du 

voyage. 

Cette prestation complementaire s'appuie sur Futilisation des services de la plate-forme de reserva- 
tion hoteliere de la societe SW-H6tels. 

Les services de la centrale de reservation sont egalement accessibles aux employes de SW- Voyages, 
a partir de Finterface Web du site extranet existant, lui-meme accessible a l'adresse http://www.sw- 
hotels.com-.8080. 

De meme, dans le cadre du partenariat entre SW- Voyages et SW-H6tels, les deux societes ont decide 
de rendre possible Faeces au systeme back-office de reservation de SW-H6tels, via une interface 
normalisee de service Web reposant sur la specification WSDL. 

Ce second canal d'acces (le service Web) s'ajoutera done au premier canal d'acces (le site Web), 
lequel restera inchange. 

La centrale de reservation automobile : SW-Voitures 

A Finstar de la prestation de reservation hoteliere offerte par SW- Voyages, une prestation comple- 
mentaire de reservation automobile est offerte par Fagence de voyages. 

Le lieu de realisation de cette prestation est egalement le lieu de destination du voyage. 

Pour ce faire, Fagence utilise les services de la centrale de reservation automobile SW-Voitures, 
capable de fournir les disponibilites offertes par les principales entreprises de location automobile. 

Les services de cette centrale de reservation sont egalement accessibles aux employes de SW- Voyages, a 
partir de Finterface Web du site extranet existant, lui-meme accessible a l'adresse http://www.sw-voitures 
.com:8080. 

Comme pour les partenariats avec SW-Air et SW-H6tels, les societes SW- Voyages et SW-Voitures 
ont pris la decision de permettre Faeces au systeme back-office de reservation de SW-Voitures, via 
une interface normalisee de service Web qui repose sur la specification WSDL. 

De la meme maniere, ce second canal d'acces (le service Web) viendra s'ajouter au premier canal 
d'acces (le site Web), lequel demeurera inchange. 
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Nouveau systeme 

En resume, les principaux faits remarques lors de F etude de la situation du systeme existant, sont 
principalement : 

• l'existence de sites Web deja accessibles chez chacun des partenaires impliques dans le processus 
etudie ; 

• la presence de systemes back-office enfouis dans les systemes d' information respectifs de chacun 
des partenaires. Ces systemes back-office sont deja accessibles a partir des sites Web classiques 
(front-office) propres a chacun des partenaires. 

Les nouvelles orientations prevues par les partenaires sont les suivantes : 

• capitalisation des infrastructures Web actuellement deployees ; 

• exposition des fonctions back-office enfouies via des interfaces normalisees de type WSDL, et 
ouverture d'un second canal d'acces (service Web) aux systemes back-office ; 

• maintien du premier canal d' acces (site Web) dans le cadre de certaines operations manuelles et/ou 
correctives. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenai- 
res sera realise sous forme d' installation d' applications Web qui viendront s'ajouter aux applications 
existantes deja disponibles. 

Le detail des produits utilises, des choix techniques et du parametrage d' installation est decrit dans le 
chapitre suivant (voir la section « Implementation » du chapitre 23). 

L'arborescence des applications Web deployees dans le serveur d' applications Tomcat retenu (voir la 
section « Implementation » du chapitre 23) est representee figure 22-1. 

Architecture generate 

L architecture globale du nouveau systeme de reservation peut ainsi etre representee de la maniere 
illustree en figure 22-2. 

Sur ce schema d' architecture generate, les quatre domaines associes aux differents partenaires de 
1' application de reservation sont figures par les quatre serveurs d' applications Java (Tomcat 4.1.12). 
Ceux-ci communiquent entre eux, via Internet (materialise par le nuage), par F intermediate du 
protocole SOAP sur HTTP. 

De meme, le poste client de l'agence de voyages (sous Internet Explorer 5.0, 5.5 ou 6.0) communi- 
que avec son serveur local en utilisant egalement le protocole SOAP sur HTTP, a travers la mise en 
ceuvre d'un composant particulier propre a Microsoft : le comportement (behavior) WebSer- 
vice 1.0.1.1120. Ce composant, specifique a l'environnement Internet Explorer (fichier webser- 
vice.htc) implemente le protocole SOAP en langage JavaScript. Par ailleurs, il prend en charge la 
specification WSDL. 
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Figure 22-1 

Arborescence des applications Web deployees dans le serveur Tomcat. 



II existe egalement une implementation equivalente du protocole SOAP pour les dernieres versions 
des navigateurs Netscape ou Mozilla. Le lecteur pourra se referer au chapitre 16 (« Les implementa- 
tions sur le poste de travail ») qui traite de ces possibilites. Lutilisation de ce composant n'est pas 
strictement necessaire dans le cadre de notre maquette, mais permet d'illustrer la facilite d'utilisation 
du produit et la simplicite d'interaction qu'il autorise avec le serveur. 

Les quatre serveurs executent F application metier speciflque a chacune des entreprises concernees. 
Dans notre exemple, seule 1' application accessible par le site Web de SW- Voyages est nouvelle et 
nous interesse. Les autres applications existent deja et les employes de la societe SW- Voyages y acce- 
dent via les sites Web respectifs des partenaires. La seule nouveaute reside done dans la publication 
d'un document WSDL de description de F interface de service Web pour chacune des applications de 
reservation des quatre partenaires. 
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Cinematique des echanges 

Le scenario peut etre decoupe en plusieurs phases : 

• une premiere phase consiste a obtenir du client les caracteristiques du voyage qu'il souhaite effec- 
tuer, a communiquer aux partenaires du processus ces informations arm qu'ils puissent les enregis- 
trer pour ensuite les exploiter ; 

• la seconde phase a pour objectif de fournir les disponibilites offertes par les differents partenaires 
et a les afficher sur le poste de travail du client, de maniere a ce qu'il puisse effectuer son choix ; 

• la troisieme phase vise a realiser la reservation proprement dite en fonction des choix retenus par 
le client et des disponibilites reelles au moment de la demande de reservation. 

Les echanges realises entre les quatre serveurs d' applications suivent la cinematique representee 
figure 22-3. 

Phase 1 : communication et enregistrement des caracteristiques du voyage 
Les principales actions possibles, durant cette phase, sont les suivantes : 

1. Demande de recherche de disponibilites : le client demande a l'agence ses disponibilites pour un 
voyage dont les caracteristiques sont enregistrees, via une nouvelle application Web, developpee 
par SW- Voyages. Les principaux elements d' information fournis par le client sont : 

- la localite de depart ; 

- la localite d'arrivee ; 

- la date de depart ; 

- la date de retour (si voyage en « aller-retour ») ; 

- le type de voyage (« aller-retour » ou « aller simple ») ; 

- le nombre de voyageurs ; 

- une option de reservation d'un vehicule (localite d'arrivee) ; 

- une option de reservation d'une chambre d'hotel (localite d'arrivee). 

2. Communication et enregistrement de la demande par SW-Air : le serveur d' applications de SW- 
Voyages communique la demande de disponibilites au serveur d' applications de la centrale de 
reservation SW-Air, lequel attribue un numero de reservation a la demande de SW- Voyages et 
enregistre la demande et ses caracteristiques dans un registre local des reservations. 

3. Restitution du numero de reservation attribue par SW-Air : le serveur d' applications de SW-Air 
renvoie le numero de reservation attribue a cette nouvelle demande au serveur d' applications de 

SW-Voyages. 

4. Communication et enregistrement de la demande par SW-Voitures : de maniere optionnelle, le 
serveur d' applications de SW-Voyages communique la demande de disponibilites au serveur 
d' applications de la centrale de reservation SW-Voitures, lequel attribue un numero de reserva- 
tion a la demande de SW-Voyages et enregistre la demande et ses caracteristiques dans un registre 
local des reservations. 
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5. Restitution du numero de reservation attribute par SW-Voitures : le serveur d' applications de SW- 
Voitures renvoie le numero de reservation attribue a cette nouvelle demande au serveur d' appli- 
cations de SW- Voyages. 

6. Communication et enregistrement de la demande par SW-H6tels : suivant l'option retenue par le 
client, le serveur d' applications de SW- Voyages communique la demande de disponibilites au 
serveur d' applications de la centrale de reservation SW-H6tels, lequel attribue un numero de 
reservation a la demande de SW- Voyages et enregistre la demande et ses caracteristiques dans un 
registre local des reservations. 

7. Restitution du numero de reservation attribue par SW-H6tels : le serveur d' applications de SW- 
Hotels renvoie le numero de reservation attribue a cette nouvelle demande au serveur d' applications 
de SW- Voyages. 

8. Enregistrement de la demande par SW- Voyages : le serveur d' applications de SW- Voyages attri- 
bue un numero de reservation a la demande du client et enregistre la demande dans un registre 
local des reservations. Cette reservation conserve les caracteristiques du voyage dont les disponi- 
bilites sont demandees par le client, ainsi que les differents numeros de reservation (identifiants) 
attribues par les partenaires concernes par la demande. Le numero de reservation attribue par 
SW- Voyages est restitue a 1' application Web cliente. 

L'ensemble des actions realisees dans cette premiere phase s'apparente a une operation concertee de 
synchronisation avant reservation, effectuee par les differents serveurs d' applications impliques dans 
le processus. 

Phase 2 : obtention et production des disponibilites de voyage 

Au debut de cette deuxieme phase, tous les serveurs d' applications ont repondu present a F invite de 
l'application Web cliente : le serveur d' applications de SW- Voyages en charge de Fagregation des 
services Web des partenaires, le serveur d' applications de SW-Air obligatoirement present dans 
toutes les operations de reservation, et les serveurs d' applications des centrales de reservation SW- 
Voitures et SW-H6tels si le client a emis un souhait de reservation complementaire d'un vehicule 
automobile ou d'une chambre d'hotel sur le lieu de destination. 

En cas d'indisponibilite de Fun des serveurs d' applications, le client final est notifie de Findisponibi- 
lite temporaire du service de reservation (agrege) et est invite a soumettre une nouvelle demande de 
recherche de disponibilites un peu plus tard. 

A Finverse, si la synchronisation des serveurs impliques s'est bien passee, la deuxieme phase peut 
etre enclenchee. Pendant cette nouvelle phase, les traitements suivants sont entrepris : 

9. Demande de production des disponibilites aeriennes : l'application Web cliente demande a 
Fagence de voyages de produire ses disponibilites aeriennes pour le voyage dont le numero de 
reservation est fourni. Cette action a lieu immediatement apres les actions de la premiere phase, 
sans action particuliere de la part de Futilisateur. 

10. Communication et production des disponibilites par SW-Air : le serveur d' applications de SW- 
Voyages demande au serveur d' applications de SW-Air de produire ses disponibilites de reserva- 
tion aerienne en fonction des caracteristiques du voyage prealablement enregistrees pour la 
demande dont le numero de reservation est fourni. 
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11. Restitution des disponibilites de SW-Air : le serveur d' applications de SW-Air renvoie ail serveur 
d' applications de SW- Voyages la collection des disponibilites automobiles que la societe est 
susceptible d'offrir en fonction des caracteristiques demandees. 

12. Restitution des disponibilites aeriennes : le serveur d' applications de SW- Voyages renvoie a 
1' application Web cliente la collection des disponibilites aeriennes que la societe est susceptible 
d'offrir en fonction des caracteristiques demandees et des disponibilites communiquees par le 
partenaire SW-Air. 

13. Demande de production des disponibilites automobiles : sur choix optionnel du client, 1' applica- 
tion Web cliente demande a l'agence de voyages de produire ses disponibilites automobiles pour 
le voyage dont le numero de reservation est fourni. Cette action a lieu immediatement apres les 
actions de la premiere phase, sans action particuliere de la part de Futilisateur. 

14. Communication et production des disponibilites par SW-Voitures : le serveur d' applications de 
SW- Voyages demande au serveur d' applications de SW-Voitures de produire ses disponibilites de 
reservation automobile en fonction des caracteristiques du voyage prealablement enregistrees 
pour la demande dont le numero de reservation est fourni. 

15. Restitution des disponibilites de SW-Voitures : le serveur d' applications de SW-Voitures renvoie 
au serveur d' applications de SW- Voyages la collection des disponibilites aeriennes que la societe 
est susceptible d'offrir en fonction des caracteristiques demandees. 

16. Restitution des disponibilites automobiles : le serveur d' applications de SW- Voyages renvoie a 
1' application Web cliente la collection des disponibilites automobiles que la societe est suscepti- 
ble d'offrir en fonction des caracteristiques demandees et des disponibilites communiquees par le 
partenaire SW-Voitures. 

17. Demande de production des disponibilites hotelieres : sur choix optionnel du client, 1' application 
Web cliente demande a l'agence de voyages de produire ses disponibilites hotelieres pour le 
voyage dont le numero de reservation est fourni. Cette action a lieu immediatement apres les 
actions de la premiere phase, sans action particuliere de la part de Futilisateur. 

18. Communication et production des disponibilites par SW-H6tels : le serveur d' applications de 
SW- Voyages demande au serveur d' applications de SW-H6tels de produire ses disponibilites de 
reservation hoteliere en fonction des caracteristiques du voyage prealablement enregistrees pour 
la demande dont le numero de reservation est fourni. 

19. Restitution des disponibilites de SW-H6tels : le serveur d' applications de SW-H6tels renvoie au 
serveur d' applications de SW- Voyages la collection des disponibilites hotelieres que la societe est 
susceptible d'offrir en fonction des caracteristiques demandees. 

20. Restitution des disponibilites hotelieres : le serveur d' applications de SW- Voyages renvoie a 
1' application Web cliente la collection des disponibilites hotelieres que la societe est susceptible 
d'offrir en fonction des caracteristiques demandees et des disponibilites communiquees par le 
partenaire SW-H6tels. 

Apres la phase de synchronisation initiale entre partenaires, F ensemble des actions realisees durant 
cette deuxieme phase correspond a une etape de preparation d'une reservation par les differents 
serveurs d' applications impliques. 
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Phase 3 : choix des disponibilites de voyage et reservation 

A Tissue de la deuxieme phase, tous les serveurs d' applications concernes par la demande de dispo- 
nibilites en cours ont renvoye leurs possibilites de reservation au serveur d' applications de SW- Voyages 
en charge de l'agregation des disponibilites et de la coordination du processus metier. Celles-ci ont 
ete collectees et retournees a destination de F application Web cliente qui est alors en mesure de les 
afficher sur le poste de travail de l'utilisateur final. 

A ce stade, l'utilisateur peut soit annuler sa demande de reservation s'il n'est pas satisfait des possi- 
bilites proposees, soit effectuer les choix necessaires parmi les disponibilites affichees et demander la 
reservation effective. 

Pendant cette derniere phase, les traitements suivants sont entrepris : 

21. Demande d'annulation ou de reservation des disponibilites choisies : 1' application Web cliente 
demande a l'agence de voyages soit d' annuler la demande de reservation dont le numero de reser- 
vation est fourni, soit de confirmer la demande de reservation dont le numero de reservation est 
fourni, ainsi que les numeros de disponibilites aeriennes (et eventuellement automobiles et/ou 
hotelieres) choisies. Cette action a lieu immediatement apres une action de l'utilisateur : l'utilisa- 
tiondubouton Annuler ou Reserver de l'interface. 

22. Communication des disponibilites choisies et reservation par SW-Air : le serveur d' applications de 
SW- Voyages demande au serveur d' applications de SW-Air soit d' annuler la demande de reserva- 
tion dont le numero de reservation est fourni, soit de confirmer la demande de reservation dont le 
numero de reservation est fourni, accompagne des numeros des disponibilites aeriennes choisies. 

23. Restitution de la confirmation d'annulation ou de reservation de SW-Air : le serveur duplica- 
tions de SW-Air renvoie au serveur d' applications de SW- Voyages la confirmation de la demande 
d'annulation ou de reservation pour la demande de reservation concernee. 

24. Communication des disponibilites choisies et reservation par SW-Voitures : le serveur d' applica- 
tions de SW- Voyages demande au serveur d' applications de SW-Voitures soit d' annuler la 
demande de reservation dont le numero de reservation est fourni, soit de confirmer la demande de 
reservation dont le numero de reservation est fourni, ainsi que le numero de la disponibilite auto- 
mobile choisie. 

25. Restitution de la confirmation d'annulation ou de reservation de SW-Voitures : le serveur d' appli- 
cations de SW-Voitures renvoie au serveur d' applications de SW- Voyages la confirmation de la 
demande d'annulation ou de reservation pour la demande de reservation concernee. 

26. Communication des disponibilites choisies et reservation par SW- Hotels : le serveur d' applications 
de SW- Voyages demande au serveur d' applications de SW-H6tels soit d' annuler la demande de 
reservation dont le numero de reservation est fourni, soit de confirmer la demande de reservation dont 
le numero de reservation est fourni, ainsi que le numero de la disponibilite hoteliere choisie. 

27. Restitution de la confirmation d'annulation ou de reservation de SW-H6tels : le serveur d' appli- 
cations de SW-H6tels renvoie au serveur d' applications de SW- Voyages la confirmation de la 
demande d'annulation ou de reservation pour la demande de reservation concernee. 

28. Confirmation de la demande d'annulation ou de reservation : le serveur d' applications de SW- 
Voyages renvoie a 1' application Web cliente la confirmation de la demande d'annulation ou de 
reservation pour la demande de reservation concernee. 
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A Tissue de cette troisieme phase, l'ensemble du processus metier de reservation a ete complete - 
ment deroule. Si l'utilisateur final a choisi de confirmer sa reservation, l'agence de voyages lui a 
communique le numero de la reservation effectuee, a rappeler dans toute correspondance ulte- 
rieure. Chacun des quatre serveurs d' applications dispose des informations necessaires au traite- 
ment effectif de la reservation par le systeme de back-office interne : transmission des caracteristi- 
ques de la reservation aux prestataires finaux (compagnies aeriennes, chaines hotelieres, etc.), 
emission des billets, de courriers de confirmation... 

Demarche de developpement 

La demarche generate de developpement du nouveau systeme de reservation peut etre organisee de la 
maniere suivante : 

1 . redaction des classes d' interface Java des services de reservation, propres a chacun des quatre parte - 
naires (classe I Reservati onServi ce . java) : ces classes ne sont pas identiques car les quatre partenaires 
n'exposent pas forcement des traitements identiques ; 

2. generation des fichiers de description des services Web (WSDL) a partir des classes d' interface 
Java (introspection) ; 

3. generation (optionnelle) des squelettes d' implementation (skeleton) des services Web a partir des 
fichiers de description des services Web (WSDL) generes ; 

4. generation (optionnelle) des classes proxy-services Java a partir des fichiers de description des 
services Web (WSDL) generes ; 

5. redaction des classes Java d' implementation des services Web : modification des classes de sque- 
lettes generees et ecriture des classes de servitude associees ; 

6. generation de clients de test des services Web produits a partir des fichiers de description des 
services Web (WSDL) generes ; 

7. redaction de F application Web cliente. 

La derniere etape (redaction de 1' application Web cliente) est traitee dans ce chapitre avant les six 
points precedents qui, eux, seront illustres dans le chapitre suivant (application Web serveur), en 
contradiction apparente avec l'ordre preconise ici. Le but est de faciliter la presentation de l'etude 
de cas et de permettre au lecteur de mieux apprehender le besoin fonctionnel et le fonctionnement de 
1' application Web avant de traiter la partie serveur. 

Bien entendu, ces differentes etapes du processus commencent a etre outillees, comme nous avons pu 
le voir dans les chapitres precedents, notamment ceux consacres aux deux plates-formes majeures 
qui sont appelees a prendre une large part du marche relatif au developpement des services Web (voir 
chapitre 14 « Les plates-formes Java » et chapitre 15 « La plate-forme .NET »). 

Deja, les acteurs principaux ont commence a proposer de nouvelles versions d'environnements de 
developpement tels que Sun ONE Studio de Sun Microsystems, WebSphere Studio Application 
Developer dTBM et WebLogic Workshop de BEA pour le monde Java, ou Visual Studio.NET de 
Microsoft. 

Pour ce premier scenario, nous nous sommes cependant contentes d'un editeur de texte simple (voir 
Notepad, UltraEdit ou TextPad par exemple), associe au compilateur J a vac issu du Java Development 
Kit (JDK) Standard Edition 1.4.1 de Sun Microsystems. 
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Developpement 

Le developpement de la premiere generation du systeme de reservation est decrit selon deux points 
de vue : F application Web de SW- Voyages (parties client et serveur) et les applications Web des 
partenaires (partie serveur seulement). Pour ce premier scenario, le developpement de ces differentes 
parties est detaille. En ce qui concerne les scenarios suivants, ceux-ci sont decrits par difference avec 
le present scenario. 

Application Web de SW-Voyages 

L'arborescence de 1' application Web de la societe SW-Voyages (contexte reservation_sw-voyages) se 
presente done telle que l'illustre la figure 22-4 : 
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Figure 22-4 

Arborescence de V application Web de la societe SW-Voyages. 



L' application complete (partie cliente et partie serveur) est entierement localisee dans le repertoire 
{XTOMCAT_HOME%}\webapps\reservation_sw- voyages du serveur Tomcat. 

Partie cliente de I'application Web de SW-Voyages 

L' application est concue pour fonctionner dans un navigateur Microsoft Internet Explorer, capable 
d'exploiter des analyseurs syntaxiques XML et XSL. Elle se limite done aux versions 5.0, 5.5 et 6.0 
du navigateur. 

L' application est egalement limitee du fait de Futilisation du comportement WebService Beha- 
vior 1 .0. 1 . 1 120 de Microsoft. Cette technologie ne fonctionne que dans les navigateurs de Microsoft. 
En contrepartie, ce comportement particulier permet au navigateur d'echanger des messages SOAP 
avec son serveur HTTP. 
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Cette partie est developpee a l'aide des technologies suivantes : 

• pages ecrites en XHTML 1 .0 ; 

• styles rediges en CSS level 1 (CSS1) ; 

• scripts ecrits en JavaScript 1.3. 

Ces technologies ont ete choisies car elles ne presentent aucune adherence a la plate-forme Java : 
elles n'utilisent notamment pas de JavaServer Pages. De ce fait, cette partie cliente de l'application 
sera aisement portable vers une autre plate-forme, sans aucune modification (possibilite utilisee dans 
le troisieme scenario). 

La fenetre initiale de l'application est representee figure 22-5 : 
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Figure 22-5 

Fenetre initiale de l'application Web cliente de la societe SW-Voyages. 



De maniere schematique, Futilisateur saisit les caracteristiques du voyage qu'il souhaite effectuer par 
l'intermediaire des controles de la partie gauche de Fecran. Lorsque ses criteres sont complets et vali- 
des, le bouton Chercher devient actif et son utilisation declenche F interrogation du serveur de 
l'agence de voyages, lequel interroge a son tour les serveurs des partenaires. 
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En retour, le serveur de Fagence de voyages recupere les disponibilites des partenaires en fonction 
des criteres saisis par l'utilisateur, les renvoie au navigateur qui les met en forme et les presente a 
l'utilisateur sous forme de tableaux (voir champs Selection du vol aller, Selection du vol retour, 
Selection de 1 'hotel et Selection du vehicule). Cela permet le deblocage des boutons Annul er et 
Reserver. L'utilisateur peut alors soit annuler sa recherche de disponibilites, soit choisir une ligne 
pour chacun des tableaux affiches, par F intermediate d'un bouton radio, et demander la reservation 
des disponibilites selectionnees. 

Dans les deux cas, le serveur de l'agence de voyages communique la decision de l'utilisateur aux 
serveurs des partenaires qui enregistrent les choix de disponibilites effectues. En cas de reservation, 
le numero de reservation attribue par le serveur de l'agence de voyages est communique au naviga- 
teur qui l'affiche a destination de l'utilisateur. 

Apres confirmation d'une reservation, la fenetre de 1' application Web de SW- Voyages se presente 
telle que l'illustre la figure 22-6 : 
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Figure 22-6 

Fenetre de V application Web de SW-Voyages apres reservation. 
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Utilisation des validateurs XHTML et CSS du W3C 

Les elements applicatifs clients ont ete valides a I'aide des validateurs XHTML (voir http://validator.w3.org) et CSS 
(voir http://jigsaw.w3.org/css-validator) du W3C. Cependant, dans le cadre reservation.html detaille plus loin 
dans ce chapitre, si on utilise I'evenement onbef oreunl oad sur I'element body, la page HTML n'est plus entiere- 
ment compatible avec la specification W3C, car cet evenement est un ajout de I'implementation Microsoft. Mais il 
n'en demeure pas moins tres utile : dans ce scenario, il est utilise pour nettoyer le registre des reservations du 
serveur lorsque I'utilisateur quitte I'application de reservation. 



Elements graphiques XHTML et CSS 

Les elements applicatifs sont deployes a la racine del' application Web, c'est-a-dire dans le repertoire 
{!8T0MCAT_H0ME%}\webapps\reservation_sw- voyages. 

La page d'accueil i ndex. html (voir code complet a telecharger sur www.editions-eyrolles.com) est decou- 
pee en trois cadres: header.html (voir code complet a telecharger sur www.editions-eyrolles.com), 
content.html (voir code complet a telecharger sur www.editions-eyrolles.com) et footer.html (voir code 
complet a telecharger sur www.editions-eyrolles.com). 

Le cadre content.html (voir code complet a telecharger sur www.editions-eyrolles.com) est lui-meme 
decoupe en deux sous-cadres : reservation.html (voir code complet a telecharger sur www.editions-eyrol- 
les.com) et avail abi 1 i ti es . html (voir code complet a telecharger sur www.editions-eyrolles.com). C'est lui 
qui contient la partie utile de I'application. 

Le cadre reservati on . html permet a I'utilisateur final de I'application Web de saisir les caracteristiques 
du voyage pour lequel il souhaite connaitre les disponibilites de l'agence de voyages. 
Ce cadre declare F utilisation d'un script qui prend en charge toute la gestion dynamique de I'appli- 
cation cliente : 

<script type="text/javascript" src=". /scripts/reservation. js" ></script> 

II declare egalement l'attachement du comportement WebService de Microsoft (fichier webser- 
vice.htc), viaunebalise <div> dont l'identifiant est service : 

<div id=" service" style="behavior:url ( ./scripts/webservice.htc)"X/div> 

Le cadre avail abi 1 ities.html est utilise pour afficher, de maniere dynamique, les disponibilites 
de l'agence de voyages en fonction des criteres fixes par I'utilisateur dans le cadre reservati on . html . 
L'utilisateur est alors en mesure de choisir les disponibilites qu'il souhaite reserver. 
Enfin, les deux sous-cadres reservation.html et availabilities.html font appel au meme fichier 
de style CSS style. ess (voir code complet a telecharger sur www.editions-eyrolles.com) pour ce qui 
concerne la presentation des ecrans (voir code complet a telecharger sur www.editions-eyrolles.com). 
Le fichier CSS est localise dans le repertoire {%TOMCAT„HOME£}\webapps\ reservati on_sw-voyages\scripts. 

Element applicatif JavaScript 

Le script reservati on. js (voir code complet a telecharger sur www.editions-eyrolles.com) constitue 
I'element le plus important de I'application Web sur le poste client (fichier localise dans le repertoire 

(%TOMCAT_HOME%}\webapps\reservation_sw-voy ages \ scripts). 

Ce script implemente tous les echanges en protocole SOAP entre le navigateur et le serveur d' appli- 
cations de l'agence de voyages. Pour cela, il met en ceuvre le comportement WebService de Micro- 
soft, attache au cadre reservation.html par F intermediate d'une balise <div>. 
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Le comportement recupere la description de service WSDL dont FURL est foumie par la variable 
RESERVATION_WSDL_URL, ce qui lui permet de decouvrir l'adresse du point d'acces au service Web, puis 
d'initier les echanges avec le serveur. 

Le script declare l'utilisation du service Web ReservationService dont la description WSDL est 
situee a l'adresse RESERVATION_WSDL_URL de la maniere suivante : 

service.useService(RESERVATION_WSDL_URL, "ReservationService") ; 

Fonction search_onclick() 

Le script effectue une demande de recherche de disponibilites via Finvocation de la methode search 
exposee par le service Web ReservationService. Cette demande correspond a Taction n°l decrite 
dans la cinematique des echanges (figure 22-3) : 

try { 

servi ce. ReservationService. call Servi ce( sea rch_call back, "search" , 
passengers, val lie, from. value, to. value, roundtrip.val ue, 
departure_day.val ue, departure_month.val ue, departure_year. value, 
arrival_day .value, arrivaljnonth. value, am'val_year.val ue, 
document. all .hotel .checked, document. al 1 .car. checked) ; 
} 
catch (e) { 

alert("erreur( "+e.number+" ) : "+e. description) ; 
} 
) 

Fonction search_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode search est realisee par la fonction search_callback(result). Cette prise en charge corres- 
pond a la fin de Faction n°8 decrite dans la cinematique des echanges (figure 22-3). 

La fonction enregistre tout d'abord le numero de reservation communique par le serveur de SW- 

Voyages : 

setReservati on Id (result. value) ; 

Puis elle precede aussitot a Finvocation des methodes getAirAvai labilities, getCarAvai labilities 
et getHotel Avai 1 abi 1 i ti es exposees par le service Web. Ces invocations correspondent aux actions 
n os 9, 13 et 17 decrites dans la cinematique des echanges (figure 22-3) : 

try { 
var service = parent. reservation. service. ReservationService; 
var reservationld = parent . reservation. getReservationldt ) ; 
servi ce . cal 1 Servi ce(get_ai rAvai 1 abi 1 i ti es_cal 1 back, 

"getAirAvai labilities" .reservationld) ; 
if (document. al 1 .hotel .checked) { 

se rv i ce. call Servi ce(get_hotel Avail abi 1 ities_callback, 
"getHotel Avail abi 1 ities" .reservationld) ; 
} 
if (document. al 1 .car. checked) { 

servi ce. call Servi ce(get_carAvail abi 1 ities_cal lback, 
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"getCarAvai labilities" .reservation Id) ; 
} 
} 

catch (e) { 

alert("erreur("+e.number+") : "+e. description) ; 
} 

Fonction get_airAvailabilities_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode getAirAvailabilities du service Web est traitee par la fonction get_airAvaila- 
bi 1 1 11 es„cal 1 back( resul t ). Cette prise en charge correspond a la fin de Taction n°12 decrite dans la 
cinematique des echanges (figure 22-3). La fonction construit dynamiquement les tableaux de dispo- 
nibilites aeriennes du cadre availabilities.html (selection des vols aller et retour), a partir de la 
deserialisation du tableau de disponibilites renvoye par le serveur et recupere de la maniere suivante : 

var availabilities - resul t. raw. getElementsByTagNameC'item") ; 

Fonction get_hotelAvailabilities_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode getHotelAvailabilities du service Web est traitee par la fonction get_hotelAvaila- 
bi 1 i t1 es^cal 1 back( resul t ). Cette prise en charge correspond a la fin de Taction n°20 decrite dans la 
cinematique des echanges (figure 22-3). La fonction construit dynamiquement le tableau de disponi- 
bilites hotelieres du cadre avai 1 abi 1 i ti es . html (selection de Thotel) a partir de la deserialisation du 
tableau de disponibilites renvoye par le serveur. Les disponibilites hotelieres sont recuperees de la 
meme maniere que les disponibilites aeriennes. 

Fonction get_carAvailabilities_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode getCarAvailabilities du service Web est effectuee par la fonction get_carAvaila- 
bi 1 i ti es^cal 1 back( resul t ). Cette prise en charge correspond a la fin de Taction n°16 decrite dans la 
cinematique des echanges (figure 22-3). La fonction construit dynamiquement le tableau de disponi- 
bilites automobiles du cadre avai 1 abi 1 i ti es . html (selection du vehicule) a partir de la deserialisation 
du tableau de disponibilites renvoye par le serveur. Les disponibilites automobiles sont recuperees de la 
meme maniere que les disponibilites aeriennes et hotelieres. 

Fonction cancel_onclick() 

La demande d'annulation de recherche de disponibilites est realisee via l'invocation de la methode 
cancel exposee par le service Web ReservationService. Cette demande correspond a Taction n°21 
decrite dans la cinematique des echanges (figure 22-3) : 

try { 

parent.reservation.service.ReservationService.callServicet 
cancel _cal Iback, "cancel " .parent. reservation. get Reservation Id ( ) ) ; 
} 
catch (e) ( 

alert("erreur("+e.number+") : "+e. description) ; 
} 
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Fonction cancel_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode cancel est traitee par la fonction cancel _cal 1 back( resul t ). Cette prise en charge correspond 
a la fin de Taction n°28 decrite dans la cinematique des echanges (figure 22-3) et annule le numero de 
reservation courant : 



I 



set Reservation Id (null ) ; 



Fonction book_onclick() 

La demande de reservation des disponibilites selectionnees par l'utilisateur est operee via l'invoca- 
tion de la methode book exposee par le service Web ReservationService. Cette demande correspond 
a Taction n°21 decrite dans la cinematique des echanges (figure 22-3) : 

try { 
parent.reservation.service.ReservationService.callService( 

book_callback, "book" , parent.reservation.getReservationldt ) , 

get_selectedChoice_id("departure_choice" ) , 

get_selectedChoice_id("arrival_choice") , 

get_selectedChoice_id("hotel_choice") , 

get_selectedChoice_id("car_choice") ) ; 
} 

catch (e) { 
alert("erreur("+e.number+" ) : "+e. description) ; 



Fonction book_callback(result) 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode book est geree par la fonction book_call back (result). Cette prise en charge correspond a la 
fin de Taction n°28 decrite dans la cinematique des echanges (figure 22-3). La fonction communique 
a l'utilisateur le numero de reservation definitif et lui propose de realiser une autre operation : 

var more = window. confirmCVotre reservation a ete enregistree sous 
le n°"+parent. reservation.getReservationldC ) 

+"\n(a rappeler dans toute correspondance) .\n\nVoulez-vous effectuer 
une autre reservation ?"); 

Fonction reservation_window_onunload() 

Lorsque l'utilisateur decide de quitter Tapplication de reservation, cela provoque T emission de 
Tevenement onunl oad sur T element body du cadre reservation. html . Fonctionnellement, cela corres- 
pond a une demande d'annulation de la recherche de disponibilites en cours. Ceci est realise via 
l'invocation de la methode cancel exposee par le service Web ReservationService. Cette demande 
correspond a Taction n°21 decrite dans la cinematique des echanges (figure 22-3) : 

I try { 
service. ReservationService.cal 1 Service ( 
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cancel_cal Iback, "cancel " ,getReservationId( ) ) ; 
} 
catch (e) ( 

alert("erreur("+e.number+") : "+e. description) ; 
} 

La prise en charge (asynchrone par callback) de la reponse du serveur suite a l'invocation de la 
methode cancel esttraitee par la fonction cancel _callback(result) vue precedemment. 

Fonction soap_error(result) 

Enfin, toutes les fonctions rappelees par callback du comportement WebService de Microsoft appel- 
lent une fonction generique soap_error( result) de detection et de signalisation des erreurs (techni- 
ques et/ou applicatives) remontees lors des echanges via le protocole SOAP. Cette fonction analyse le 
resultat de l'invocation et affiche un message d'erreur en cas d'anomalie : 

function soap_error(resul t) { 
if (result. error) ( 

var faultCode = resul t.errorDetail .code; 

var faultString = result. errorDetail .string; 

var errorString = faultCode + " - " + faultString; 

alertC'A service error occurred : " + errorString); 

return true; 
} 

return false; 
} 

Partie serveur de I'application Web de SW-Voyages 
L' implementation de cette partie est traitee chapitre 23. 

Applications Web des partenaires de SW-Voyages 

Face au serveur d' applications de Fagence de voyages, chacun des partenaires de SW-Voyages 
dispose de sa propre application Web existante (partie cliente et partie serveur). Pour simplifier, nous 
postulons que la partie cliente existante reste inchangee et n'entre pas dans le cadre de ce scenario. 

De fait, seule la partie serveur de I'application sera consideree, car elle va permettre d'illustrer la 
continuite de service entre le navigateur de l'utilisateur final et les serveurs d' applications des centra- 
les de reservation, via le serveur de l'agence de voyages. Nous pouvons considerer que l'implemen- 
tation serveur presentee dans le chapitre suivant est une evolution du systeme existant. 

Par ailleurs, 1' implementation de la centrale de reservation SW-Air constituera le seul exemple repro- 
duit dans ce scenario. En effet, les implementations des deux autres centrales de reservation SW- 
Hotels et SW-Voitures sont calquees sur le meme modele et leur presentation n'apporterait pas de 
precisions supple mentaires. 

L'arborescence de I'application Web de la societe SW-Air (contexte reservation_sw-ai r) se presente 
done telle que l'illustre la figure 22-7 : 
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Figure 22-7 

Arborescence de I 'application Web de la societe SW-Air. 

L' application complete (partie cliente et partie serveur) est entierement localisee dans le repertoire 
{%TOMCAT_HOME%}\webapps\reservation_sw-air du serveur Tomcat. 

Partie cliente des applications Web des partenaires de SW-Voyages 
Cette partie des applications n'est pas consideree (voir ci-avant). 

Partie serveur des applications Web des partenaires de SW-Voyages 
L' implementation de cette partie est traitee chapitre 23. 



Constat 



A partir de ce premier scenario, entierement realise sans outils de developpement particuliers, nous avons : 

• analyse, con§u, developpe et deploye une application simple de reservation de voyages, capable de 
federer les capacites applicatives des systemes d' information respectifs des quatre partenaires 
industriels concernes ; 

• utilise une implementation Java du protocole de communication SOAP sur HTTP, enfouie dans un 
serveur d' applications partiellement J2EE (pas d' implementation des specifications EJB et JMS) 
et une implementation JavaScript du protocole de communication SOAP sur HTTP incluse dans le 
comportement WebService de Microsoft ; 

• illustre une demarche de developpement adaptee a la realisation d'une application Web destinee a 
fonctionner dans le cadre d'une architecture orientee services (AOS). 
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De cette premiere experience, nous pouvons deja tirer de nombreux enseignements : 

• La mise en ceuvre d' une telle architecture est relativement simple, et demande tres peu de ressources : 
ici, le seul element nouveau, introduit par rapport aux architectures Web d'aujourd'hui, est le moteur 
d'execution SOAP. 

• Les temps de reponse, contrairement a certaines idees recues, sont proches de ceux que nous obte- 
nons dans des applications Web classiques, et ce, meme si les serveurs d' applications sont 
deployes sur des machines disseminees sur Internet. 

• L' application de reservation est totalement indisponible si un seul des serveurs d' applications est 
momentanement indisponible, sature ou en phase de maintenance. II en est de meme si Tun des 
serveurs souffre de conditions d'acces reseau execrables. Dans le cadre de certaines applications, 
ce fonctionnement en mode synchrone devra pouvoir etre remplace par un mode asynchrone, a 
base de systeme de gestion de files d'attente, plus apte a prendre en charge ces problemes d'indis- 
ponibilite temporaire. 

• Si Fun des serveurs d' applications tombe en erreur apres que d'autres serveurs ont confirme leur 
reservation, le systeme d' information se retrouve dans un etat instable. Le serveur d' applications 
de SW-Voyages, qui pilote Fagregation de services, peut chercher a compenser Fanomalie en 
annulant la reservation aupres des serveurs qui avaient confirme la reservation, mais sans assu- 
rance du resultat. Indubitablement, il manque ici un systeme de gestion de la transaction metier, 
soit synchrone (transaction courte avec confirmation en deux etapes), soit asynchrone (transaction 
longue avec systeme de compensation). 

• L'enchainement des appels de methodes sur les implementations des services Web est code direc- 
tement dans les programmes clients et F invocation des methodes est directe. Les scenarios 
d' appels ne sont pas decrits sous une forme externe interpretee au moment de F execution. 

• Les adresses des documents WSDL des differents partenaires sont codees directement dans les 
programmes clients. Aucun changement de Fune de ces URL n'est possible sans recompilation. II 
manque ici un mecanisme de recherche dynamique (lookup) de ces descriptions sur Internet. 

Le deuxieme scenario va permettre d'illustrer comment lever une partie des faiblesses de F architecture 
statique synchrone. 

Scenario n°2 (architecture dynamique - implementation Java) 

La premiere version du service Web de Fagence de voyages nous a permis d'illustrer comment develop- 
per un service de reservation de voyages capable de s'appuyer sur une infrastructure Web existante. 

La mise en ceuvre de cette version initiale nous a revele un certain nombre de faiblesses, parmi 
lesquelles : 

• le codage statique des adresses de descriptions WSDL des services Web des differents parte- 
naires de Fagence de voyages : ceci est tres contraignant car le moindre changement dans le plan 
d'adressage de Fun des intervenants oblige tous ses partenaires a recompiler simultanement 
leurs applications clientes ; 
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• le schema de partenariat relativement limite : celui-ci ne permet pas a l'agence de voyages de 
s'adresser a d'autres centrales de reservation que celles qui sont referencees de maniere statique 
dans cette premiere implementation de son service Web de reservation. 

De meme, ce premier scenario a mis en ceuvre, outre F implementation de SOAP via le comportement 
WebService de Microsoft cote navigateur, une seule implementation SOAP Java du cote serveur. 
Ceci pourrait laisser croire que la meme implementation SOAP est necessaire a chacune des extremi- 
tes de la communication et que l'application cliente et l'application serveur sont contraintes de passer 
par la pour communiquer entre elles par F intermediate de ce protocole. Mais il n'en est rien et les 
deuxieme et troisieme scenarios vont apporter un nouvel eclairage sur ce point. 



Evolution 

Depuis Fintroduction de la premiere version de son service Web de reservation, l'agence de voyages 
SW- Voyages s'est fortement impliquee dans la formalisation et la modelisation, au niveau de sa bran- 
che d'activite economique, du domaine de la reservation de voyages. Cet effort s'est essentiellement 
traduit par la mise en place d'une organisation sectorielle en charge de cette standardisation : Forga- 
nisation SW- Tourisme-xml.org. Cette organisation s'est notamment attachee a normaliser un modele 
de description abstraite de reservation d'un voyage. 

Par ailleurs, les differents partenaires de SW- Voyages se sont appliques a faire de meme, dans leurs 
secteurs economiques respectifs. Ces efforts d' organisation se sont traduits par l'apparition de 
nouvelles organisations dans chacun de ces secteurs : 

• SW-Aviation-xml.org dans le secteur du transport aerien ; 

• SW- Automobilisme-xml.org dans le secteur de F automobile ; 

• SW-Hotellerie-xml.org dans le domaine de l'hotellerie. 

Bien entendu, ces quatre nouvelles organisations sont des organismes a but non lucratif, dont Fobjec- 
tif est de promouvoir Forganisation, la standardisation et la reglementation des secteurs economiques 
correspondants. 

Les quatre partenaires du systeme de reservation de l'agence de voyages SW- Voyages ont done 
decide de se conformer a ces changements intervenus dans leurs domaines respectifs, et ainsi de 
developper une seconde generation de ce systeme. 

Nouveau systeme 

En resume, les principaux faits remarques lors de F etude de la situation du systeme existant, sont 
principalement : 

• l'existence d'une premiere generation operationnelle de services Web deja disponibles chez 
chacun des partenaires impliques dans le processus etudie ; 

• Femergence de nouveaux partenaires dans le paysage economique respectif de chacun des quatre 
partenaires commerciaux, et la necessite de prendre en compte leurs recommendations en termes 
de standards et de reglementation. 
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Les orientations prevues par les partenaires dans le cadre du deploiement de la seconde generation 
des systemes de reservation sont les suivantes : 

• capitalisation sur les infrastructures Web deployees lors de la premiere phase de deploiement (voir 
la section « Scenario n°l ») ; 

• publication des implementations des services de reservation de chacun des partenaires dans 
Fannuaire UDDI public, et referencement des descriptions de services de reservation abstraits, 
standardises et publies par les organisations sectorielles ; 

• ouverture des systemes de reservation des differents partenaires actuels vers la possibility 
d'accueillir de nouveaux partenaires (clients ou fournisseurs). 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenai- 
res est maintenu sous forme d' installation d' applications Web. En ce qui concerne les nouveaux 
partenaires (organisations sectorielles), le deploiement sera egalement realise sous cette forme. 

Le detail des produits utilises, des choix techniques et du parametrage d' installation est decrit dans le 
chapitre 24 (voir la section « Implementation »). 

Architecture generale 

L architecture globale de la seconde generation du systeme de reservation peut etre representee 
comme en figure 22-8. 

Sur ce schema d' architecture generale, les quatre domaines associes aux differents partenaires 
commerciaux de 1' application de reservation sont figures par quatre serveurs d' applications Java 
(Tomcat 4.1.12). lis sont rejoints par les quatre nouveaux domaines lies aux organisations sectorielles 
qui standardisent et reglementent les procedures de reservation dans leurs domaines de competence 
respectifs. Ceux-ci sont egalement heberges par quatre nouveaux serveurs d' applications Java sous 
Tomcat 4.1.12. Un neuvieme serveur heberge un nceud d'annuaire UDDI. Ce dernier joue le role 
d'un nceud de Fannuaire public (UBR) ou interprofessionnel et est egalement un serveur Java (Glue 
Professional 3.0.1). 

Tous ces serveurs communiquent, via Internet (materialise par le nuage), soit par l'intermediaire du 
protocole SOAP sur HTTP (quatre serveurs commerciaux, plus le serveur UDDI), soit par le proto- 
cole HTTP directement (quatre serveurs organisationnels). 

A l'image du premier scenario, le poste client de l'agence de voyages (sous Internet Explorer 5.0, 5.5 
ou 6.0) est conserve et communique toujours avec son serveur local en utilisant le protocole SOAP 
sur HTTP via le comportement WebService 1 .0. 1 . 1 120 de Microsoft. 

Par rapport au premier scenario, nous utilisons ici une implementation SOAP supplementaire. En 
effet, le produit Glue Professional vient avec sa propre implementation du protocole SOAP. Les 
quatre serveurs commerciaux communiquent toujours par l'intermediaire de 1' implementation 
Apache SOAP 2.3.1. En revanche, le serveur de SW- Voyages dialogue avec le nceud de Fannuaire 
UDDI via F implementation Apache SOAP et ce dernier lui repond par le biais de F implementation 
SOAP de Glue. 
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Cinematique des echanges 

Le scenario peut etre decoupe en plusieurs phases, avec une phase supplemental par rapport ail 
premier scenario : 

• Une premiere phase reprend partiellement la premiere phase du premier scenario : il s'agit 
d'obtenir du client les caracteristiques du voyage qu'il souhaite effectuer, puis de rechercher, via 
un annuaire UDDI, les descriptions de services abstraits publiees par les organisations sectorielles 
concernees, et enfin de retrouver les points d'acces des services des societes commerciales parte- 
naires qui les implemented. 

• La deuxieme phase equivaut en grande partie a la premiere phase du premier scenario : sa finalite 
consiste a communiquer aux societes commerciales partenaires localisees dans la premiere phase 
les informations fournies par le client arm qu'elles puissent les enregistrer pour ensuite les 
exploiter. 

• La troisieme phase correspond a la deuxieme phase du premier scenario et a toujours pour objectif 
de fournir les disponibilites offertes par les differents partenaires et de les afficher sur le poste de 
travail du client de maniere a ce qu'il puisse effectuer son choix. 

• La quatrieme phase est equivalente a la troisieme phase du premier scenario : elle represente 
toujours la realisation de la reservation proprement dite en fonction des choix retenus par le client 
et des disponibilites reelles au moment de la demande de reservation. 

Les echanges realises entre les quatre serveurs d' applications des centrales de reservation et le nceud 
de 1' annuaire UDDI suivent la cinematique decrite figure 22-9. 

Les echanges avec les serveurs des organisations sectorielles ne sont pas figures ici car ils se limitent 
a des acces (GET) par le protocole HTTP, via l'utilisation des balises d'import des fichiers de 
description des services Web par les implementations WSDL. 

Phase 1 : recherche des modeles et localisation des partenaires de reservation 
Dans la liste des actions decrites ci-apres : 

• L'action n°l consiste en une interaction du navigateur avec son serveur local (SW- Voyages). 

• Les actions n°2 a n°7 represented une suite d' interactions entre le serveur local (SW- Voyages) de 
Fagence et le nceud de 1' annuaire UDDI (SW-Registre-UDDI), afin de retrouver le modele abstrait 
de reservation aerienne (pub lie vers 1' annuaire UDDI par F organisation SW- Aviation-XML) et le 
point d'acces au service du partenaire qui l'implemente (publie vers l'annuaire UDDI par l'entreprise 
commerciale SW-Air). 

• Les actions n°8 a n°13 constituent une suite d'interactions entre le serveur local (SW- Voyages) de 
Fagence et le nceud de l'annuaire UDDI (SW-Registre-UDDI) afin de retrouver le modele abstrait 
de reservation automobile (publie par F organisation SW-Automobilisme-XML) et le point d'acces 
au service du partenaire qui l'implemente (publie par l'entreprise commerciale SW-Voitures). 

• Les actions n°14 a n°19 correspondent a une suite d'interactions entre le serveur local (SW- 
Voyages) de Fagence et le nceud de l'annuaire UDDI (SW-Registre-UDDI) effectuees afin de 
retrouver le modele abstrait de reservation hoteliere (publie par Forganisation SW-H6tellerie- 
XML) et le point d'acces au service du partenaire qui l'implemente (publie par l'entreprise 
commerciale SW-H6tels). 
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Station de travail 
utilisateur SW- Voyages 




Serveur d'applications 
SW-Voitures {« distant ») 



Serveur d'applications 
SW-H6tels (« distant ») 



Figure 22-9 

Cinematique des echanges entre partenaires du systeme de reservation de deuxieme generation 
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Les principales actions possibles, durant cette phase, sont les suivantes : 

1. Demande de recherche de disponibilites : le client demande a l'agence ses disponibilites pour un 
voyage dont les caracteristiques sont enregistrees via F application Web existante de SW- Voyages 
(voir « Scenario n°l »). Les elements d'information fournis par le client sont inchanges. 

2. Recherche du modele de reservation aerienne via l'annuaire UDDI : le serveur d' applications de 
SW- Voyages recherche, par l'intermediaire de l'annuaire UDDI, la description WSDL du service 
de reservation aerienne publie par l'organisation www.sw-aviation-xml.org. 

3. Restitution par l'annuaire UDDI du modele de reservation aerienne publie : le nceud de 
l'annuaire UDDI renvoie au serveur d' applications de SW- Voyages les structures de donnees qui 
decrivent le modele de reservation aerienne recherche. 

4. Recherche des societes commerciales du secteur de la reservation aerienne : a partir de l'identi- 
fiant du modele de reservation aerienne renvoye par l'annuaire UDDI, le serveur d' applications 
de SW-Voyages recherche, par l'intermediaire de l'annuaire UDDI, l'ensemble des societes 
commerciales qui implemented le service de reservation aerienne dont le modele a ete recupere 
precedemment. 

5. Restitution par l'annuaire UDDI des societes commerciales du secteur de la reservation 
aerienne : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW-Voyages les 
structures de donnees qui correspondent aux entites economiques fournissant un service qui 
implemente le modele de reservation aerienne recherche. 

6. Recherche du point d'acces au service de la centrale de reservation aerienne partenaire : a partir 
de l'identinant du partenaire de reservation aerienne, recupere parmi les structures de donnees 
renvoyees lors de Taction precedente, le serveur d' applications de SW-Voyages recherche, par 
l'intermediaire de l'annuaire UDDI, le service ou l'ensemble des services et de leurs points 
d'acces associes qui implemente(nt) le modele abstrait de reservation aerienne. 

7. Restitution par l'annuaire UDDI du point d'acces au service de la centrale de reservation 
aerienne partenaire : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW-Voya- 
ges les structures de donnees qui correspondent au(x) service(s) implementant le modele de 
reservation aerienne recherche. Si plusieurs implementations existent, la logique applicative du 
serveur d' applications de SW-Voyages determine celle qui doit etre utilisee en fonction de crite- 
res propres a l'application ou a un contrat de service passe entre les deux partenaires et recupere 
le point d'acces correspondant. 

8. Recherche du modele de reservation automobile via l'annuaire UDDI : le serveur d' applications 
de SW-Voyages recherche, par l'intermediaire de l'annuaire UDDI, la description WSDL du 
service de reservation automobile publie par l'organisation www.sw-automobilisme-xml.org. 

9. Restitution par l'annuaire UDDI du modele de reservation automobile publie : le nceud de 
l'annuaire UDDI renvoie au serveur d' applications de SW-Voyages les structures de donnees qui 
decrivent le modele de reservation automobile recherche. 

10. Recherche des societes commerciales du secteur de la reservation automobile : a partir de l'iden- 
tinant du modele de reservation automobile renvoye par l'annuaire UDDI, le serveur d' applica- 
tions de SW-Voyages recherche, par l'intermediaire de l'annuaire UDDI, l'ensemble des societes 
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commerciales ou centrales de reservation qui implemented le service de reservation automobile 
dont le modele a ete recupere prealablement. 

11. Restitution par l'annuaire UDDI des societes commerciales du secteur de la reservation automo- 
bile : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW- Voyages les structu- 
res de donnees qui correspondent aux entites economiques susceptibles d'offrir (au moins) un 
service qui implemente le modele de reservation automobile recherche. 

12. Recherche du point d'acces au service de la centrale de reservation automobile partenaire : a 
partir de l'identifiant du partenaire de reservation automobile, recupere parmi les structures de 
donnees renvoyees lors de Faction precedente, le serveur d' applications de SW- Voyages recher- 
che, par l'intermediaire de l'annuaire UDDI, le service ou l'ensemble des services et de leurs 
points d'acces associes qui implemente(nt) le modele abstrait de reservation automobile. 

13. Restitution par l'annuaire UDDI du point d'acces au service de la centrale de reservation automo- 
bile partenaire : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW- Voyages 
les structures de donnees correspondant au(x) service(s) qui implemente(nt) le modele de reser- 
vation automobile recherche. Comme dans le cas de la reservation aerienne, si plusieurs imple- 
mentations existent, la logique applicative du serveur d' applications de SW- Voyages determine 
celle qui doit etre utilisee en fonction de cri teres propres a F application ou a un contrat de service 
passe entre les deux partenaires et recupere le point d'acces correspondant. 

14. Recherche du modele de reservation hoteliere via l'annuaire UDDI : le serveur d' applications de 
SW- Voyages recherche, par l'intermediaire de l'annuaire UDDI, la description WSDL du service 
de reservation hoteliere, publie par Forganisation www.sw-hotellerie-xml.org. 

15. Restitution par l'annuaire UDDI du modele de reservation hoteliere publie : le nceud de 
l'annuaire UDDI renvoie au serveur d' applications de SW- Voyages les structures de donnees qui 
decrivent le modele de reservation hoteliere recherche. 

16. Recherche des societes commerciales du secteur de la reservation hoteliere : a partir de l'identi- 
fiant du modele de reservation hoteliere renvoye par l'annuaire UDDI, le serveur d' applications 
de SW-Voyages recherche, par l'intermediaire de l'annuaire UDDI, l'ensemble des societes 
commerciales ou centrales de reservation qui implemented le service de reservation hoteliere 
dont le modele a ete recupere prealablement. 

17. Restitution par l'annuaire UDDI des societes commerciales du secteur de la reservation hote- 
liere : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW-Voyages les structu- 
res de donnees qui correspondent aux entites economiques susceptibles d'offrir un service (au 
moins) qui implemente le modele de reservation hoteliere recherche. 

18. Recherche du point d'acces au service de la centrale de reservation hoteliere partenaire : a partir 
de l'identifiant du partenaire de reservation hoteliere, recupere parmi les structures de donnees 
renvoyees lors de Faction precedente, le serveur d' applications de SW-Voyages recherche, par 
l'intermediaire de l'annuaire UDDI, le service ou l'ensemble des services et de leurs points 
d'acces associes qui implemente(nt) le modele abstrait de reservation hoteliere. 

19. Restitution par l'annuaire UDDI du point d'acces au service de la centrale de reservation hote- 
liere partenaire : le nceud de l'annuaire UDDI renvoie au serveur d' applications de SW-Voyages 
les structures de donnees correspondant au(x) service(s) qui implemente(nt) le modele de reser- 
vation hoteliere recherche. Si plusieurs implementations existent, la logique applicative du 
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serveur d' applications de SW- Voyages determine celle qui doit etre utilisee en fonction de crite- 
res propres a l'application ou a un contrat de service passe entre les deux partenaires et recupere 
le point d'acces correspondant. 

Cette premiere phase est done presque entierement nouvelle par rapport au premier scenario. En fait, 
seule la premiere action de l'utilisateur reste identique. Les dix-huit actions qui suivent sont totale- 
ment nouvelles, elles decrivent les tractations qui s'operent entre le serveur d' applications de 
l'agence de voyages et le nceud de Fannuaire UDDI dans le but de recuperer une collection d'adres- 
ses Internet (URL). 

Ces adresses vont etre ensuite utilisees par le serveur de l'agence de voyages, durant la deuxieme 
phase decrite ci-apres, pour poursuivre le dialogue du processus de reservation avec les serveurs des 
centrales de reservation, partenaires obliges de l'agence de voyages. 

Phase 2 : communication et enregistrement des caracteristiques du voyage 

Les actions de cette deuxieme phase correspondent aux actions n° 2 a n°8 de la premiere phase du 
premier scenario (voir « Scenario n°l »). Le contenu de ces actions reste inchange. La correspon- 
dance des actions est rappelee ici pour memoire. 

20. Communication et enregistrement de la demande par SW-Air : voir section « Scenario n° 1 », 
phase 1, action n°2. 

21. Restitution du numero de reservation attribue par SW-Air: voir section « Scenario n°l », 
phase 1, action n°3. 

22. Communication et enregistrement de la demande par SW-Voitures : voir section « Scenario 
n°l », phase 1, action n°4. 

23. Restitution du numero de reservation attribue par SW-Voitures : voir section « Scenario n°l », 
phase 1, action n°5. 

24. Communication et enregistrement de la demande par SW-H6tels : voir section « Scenario n° 1 », 
phase 1, action n°6. 

25. Restitution du numero de reservation attribue par SW-H6tels : voir section « Scenario n°l », 
phase 1, action n°7. 

26. Enregistrement de la demande par SW- Voyages : voir section « Scenario n°l », phase 1, action 
n°8. 

L'ensemble des actions realisees dans cette deuxieme phase s'apparente toujours a une operation 
concertee de synchronisation avant reservation, effectuee par les differents serveurs d'applications 
impliques dans le processus. Des le debut de cette phase, les serveurs d'applications des organisa- 
tions sectorielles, ainsi que le nceud de Fannuaire UDDI, ne jouent plus aucun role dans le processus 
global de reservation : les quatre partenaires commerciaux se sont localises et peuvent commencer le 
processus de reservation proprement dit. 

Phase 3 : obtention et production des disponibilites de voyage 

Les actions de cette troisieme phase correspondent aux actions n°9 a n°20 de la deuxieme phase du 
premier scenario (voir la section « Scenario n°l »). Le contenu de ces actions reste inchange. La 
correspondance des actions est rappelee ici pour memoire. 
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Au debut de cette troisieme phase, tous les serveurs d' applications ont repondu present a l'invite de 
l'application Web cliente : le serveur d' applications de SW- Voyages en charge de l'agregation des 
services Web des partenaires, le serveur d' applications de SW-Air obligatoirement present dans 
toutes les operations de reservation, les serveurs d' applications des societes SW-Voitures et SW- 
Hotels si le client a emis un souhait de reservation complementaire d'un vehicule ou d'une chambre 
d' hotel sur le lieu de destination. 

En cas d'indisponibilite de Tun des serveurs d'application, le client final est notifie de l'indisponibilite 
temporaire du service de reservation (agrege) et il est invite a soumettre une nouvelle demande de 
recherche de disponibilites un peu plus tard. Cette strategie est evidemment limitee : une seconde 
version de l'application pourrait repartir automatiquement a la recherche d'un autre prestataire de servi- 
ces dont le serveur est accessible, et demander a l'utilisateur de soumettre une nouvelle demande seule- 
ment en derniere instance. Nous touchons la le point sensible de la complexite de mise en ceuvre 
d' applications qui utilisent dynamiquement des services Web : la strategie de configuration dynamique 
de F architecture est le resultat de la combinaison, d'une part, de l'application d'une logique fonction- 
nelle aussi sophistiquee que Ton veut (les criteres metier du choix du partenaire et eventuellement de 
services concurrents), et d' autre part, d'une logique operationnelle de prise en compte de la possibilite 
de defaillance partielle propre a toute architecture repartie. 

A l'inverse, si la synchronisation des serveurs impliques s'est bien passee, la troisieme phase peut etre 
enclenchee. Pendant cette nouvelle phase, les traitements suivants sont entrepris : 

27. Demande de production des disponibilites aeriennes : voir section « Scenario n°l », phase 2, 
action n°9. 

28. Communication et production des disponibilites par SW-Air: voir section « Scenario n°l », 
phase 2, action n°10. 

29. Restitution des disponibilites de SW-Air : voir section « Scenario n°l », phase 2, action n°l 1. 

30. Restitution des disponibilites aeriennes : voir section « Scenario n°l », phase 2, action n°12. 

31. Demande de production des disponibilites automobiles : voir section « Scenario n°l », phase 2, 
action n° 13. 

32. Communication et production des disponibilites par SW-Voitures : voir section « Scenario n° 1 », 
phase 2, action n°14. 

33. Restitution des disponibilites de SW-Voitures : voir section « Scenario n°l », phase 2, action 
n°15. 

34. Restitution des disponibilites automobiles : voir section « Scenario n°l », phase 2, action n°16. 

35. Demande de production des disponibilites hotelieres : voir section « Scenario n°l », phase 2, 
action n°17. 

36. Communication et production des disponibilites par SW-H6tels : voir section « Scenario n°l », 
phase 2, action n°18. 

37. Restitution des disponibilites de SW-H6tels : voir section « Scenario n°l », phase 2, action n°19. 

38. Restitution des disponibilites hotelieres : voir section « Scenario n°l », phase 2, action n°20. 
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Apres la phase de synchronisation initiale entre partenaires, F ensemble des actions realisees durant 
cette troisieme phase coiTespond a une etape de preparation d'une reservation par les differents 
serveurs d' applications impliques. 

Phase 4 : choix des disponibilites de voyage et reservation 

Les actions de cette quatrieme phase correspondent aux actions n°21 a n°28 de la troisieme phase du 
premier scenario (voir la section « Scenario n°l »). Le contenu de ces actions reste inchange. La 
correspondance des actions est rappelee ici pour memoire. 

A Tissue de la troisieme phase, tous les serveurs d' applications concernes par la demande de dispo- 
nibilites en cours ont renvoye leurs possibilites de reservation au serveur d' applications de SW- Voya- 
ges, en charge de l'agregation des disponibilites. Celles-ci ont ete collectees et retournees a destina- 
tion de F application Web cliente qui est alors en mesure de les afficher sur le poste de travail de 
l'utilisateur final. 

A ce stade, l'utilisateur peut, soit annuler sa demande de reservation s'il n'est pas satisfait des possi- 
bilites proposees, soit effectuer les choix necessaires parmi les disponibilites affichees et demander la 
reservation effective. 

Pendant cette derniere phase, les traitements suivants sont entrepris : 

39. Demande d'annulation ou de reservation des disponibilites choisies : voir section« Scenario 
n°l », phase 3, action n°21. 

40. Communication des disponibilites choisies et reservation par SW-Air : voir section « Scenario 
n°l », phase 3, action n°22. 

41. Restitution de la confirmation d'annulation ou de reservation de SW-Air : voir section « Scenario 
n°l », phase 3, action n°23. 

42. Communication des disponibilites choisies et reservation par SW-Voitures : voir section « Scena- 
rio n°l », phase 3, action n°24. 

43. Restitution de la confirmation d'annulation ou de reservation de SW-Voitures : voir section 
« Scenario n°l », phase 3, action n° 25. 

44. Communication des disponibilites choisies et reservation par SW-H6tels : voir section « Scenario 
n°l », phase 3, action n°26. 

45. Restitution de la confirmation d'annulation ou de reservation de SW-H6tels : voir section 
« Scenario n°l », phase 3, action n°27. 

46. Confirmation de la demande d'annulation ou de reservation : voir section « Scenario n°l », 
phase 3, action n°28. 

Demarche de developpement 

La demarche generate de developpement du nouveau systeme de reservation est presque identique a 
celle qui a ete utilisee dans le premier scenario. II faut cependant signaler un changement notable : les 
descriptions de services Web (WSDL) ne sont plus generees a partir d'une classe d'interface Java, 
mais au contraire precedent le developpement des classes d'interface. Ces descriptions de services 
Web sont redigees et publiees par les organisations sectorielles et deviennent des elements de speci- 
fication qui s'imposent aux entreprises de ces memes secteurs economiques. 
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Developpement 

Le developpement de la deuxieme generation du systeme de reservation introduit peu de change- 
ments par rapport a la premiere generation deployee. L' element le plus impacte de la configuration 
est la partie serveur de 1' application Web de SW- Voyages, laquelle doit implementer F usage d'un 
annuaire de services UDDI, associe a une strategie de recherche et de localisation de ses partenaires. 

Application Web de SW-Voyages 

L'arborescence de l'application Web de la societe SW-Voyages (contexte reservation_sw-voyages) 
reste identique a celle du premier scenario, a l'exception des repertoires schemas et servi ces-type qui 
disparaissent au profit de l'application de l'organisation sectorielle SW-Tourisme-XML dont depend 
l'agence de voyages. 

Partie cliente de l'application Web de SW-Voyages 

La partie cliente de l'application Web reste strictement identique a celle qui a ete deployee dans le 
cadre du premier scenario. Les seuls changements introduits par cette seconde generation portent 
uniquement sur la partie serveur de l'application Web de SW-Voyages. 

Partie serveur de l'application Web de SW-Voyages 
L' implementation de cette partie est traitee chapitre 24. 

Applications Web des partenaires de SW-Voyages 

Par rapport au premier scenario, les applications Web deployees par les partenaires sont inchangees 
et demeurent strictement identiques aux versions de la premiere generation. 

Seuls les descripteurs de deploiement ont ete modifies pour tenir compte du changement de l'espace 
de noms associe aux types de donnees serialises passes sous le controle des organismes sectoriels 
(voir chapitre 24). 

Le developpement de la deuxieme generation du service Web de reservation de SW-Voyages n'a 
done qu'un impact extremement limite sur les systemes d'information de ses partenaires. 

Partie cliente des applications Web des partenaires de SW-Voyages 

Cette partie des applications des partenaires n'est pas consideree. Pour simplifier, nous postulons que 
la partie cliente existante reste inchangee et n'entre pas dans le cadre de ce scenario. 

Partie serveur des applications Web des partenaires de SW-Voyages 
L implementation de ces parties est traitee chapitre 24. 



Constat 



A partir de ce deuxieme scenario, egalement realise sans outils de developpement particuliers, nous 
avons : 

• analyse, concu, developpe et deploye une seconde generation de l'application simple de reser- 
vation de voyages illustree dans le premier scenario, toujours capable de federer les capacites 
applicatives des systemes d'information respectifs des quatre partenaires industriels concernes, qui 
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integre en outre les capacites de standardisation et d' organisation des organisations sectorielles 
auxquelles sont rattaches les partenaires industriels ; 

• mis en ceuvre une implementation d'annuaire UDDI qui introduit une nouvelle implementation 
Java du protocole de communication SOAP sur HTTP enfouie dans le moteur d' execution du 
serveur Glue Professional : finalement, cette seconde maquette met en ceuvre trois implementations 
differentes du protocole SOAP (deux Java et une JavaScript) ; 

• supprime les adresses statiques des documents WSDL des differents partenaires codees directe- 
ment dans les programmes clients de la premiere generation du systeme de reservation. Tout chan- 
gement de l'une de ces URL est maintenant possible sans recompilation. Le mecanisme de 
recherche dynamique (lookup) de ces descriptions sur Internet a introduit une grande souplesse 
d' utilisation du logiciel pour F ensemble des partenaires concernes, voire des possibilites d'ouverture 
vers de nouveaux partenaires. 

De cette nouvelle experience, nous pouvons deja tirer de nombreux enseignements : 

• La mise en ceuvre d'une telle architecture reste relativement simple, et demande toujours tres peu 
de ressources : ici, le seul element nouveau, introduit par rapport a 1' architecture presentee dans le 
premier scenario, est le serveur UDDI. 

• Les temps de reponse demeurent tout a fait corrects par rapport a ceux obtenus dans le premier 
scenario : le surcout introduit par la recherche des partenaires via Fannuaire UDDI ne se manifeste 
qu'a la premiere invocation de F application Web (acquisition statique des points d'acces des 
partenaires commerciaux). 

• Le remplacement d'une implementation de service Web par une autre est totalement indolore et 
peut etre realise de maniere totalement transparente : on approche ainsi de Fobjectif essentiel 
affiche par les architectures a base de composants, mais jamais reellement atteint jusqu'a present. 

Cependant, une partie des faiblesses relevees lors du premier scenario restent toujours presentes, a 
s avoir : 

• L application de reservation reste totalement indisponible si un seul des serveurs d' applications est 
momentanement indisponible, sature ou en phase de maintenance. II en est de meme si Fun des 
serveurs souffre de conditions d'acces reseau execrables. 

• Si Fun des serveurs d' applications tombe en erreur apres que d'autres serveurs ont confirme leur 
reservation, le systeme d'information se retrouve toujours dans un etat instable. 

• L'enchainement des appels de methodes sur les implementations des services Web demeure code 
directement dans les programmes clients et Finvocation des methodes est toujours directe. 

Scenario n°3 (architecture dynamique- implementation .NET) 

La seconde version du service Web de Fagence de voyages a montre comment mettre en ceuvre une 
architecture dynamique qui s'appuie sur un annuaire de services UDDI. Cette nouvelle generation du 
systeme de reservation a permis d'eliminer le codage statique des adresses de descriptions WSDL des 
services Web des differents partenaires de Fagence de voyages. II est maintenant possible d'etendre 
les partenariats vers d'autres acteurs qui respectent les standards edictes par les organisations profes- 
sionnelles du secteur economique de SW- Voyages et de ses partenaires. 
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D'un point de vue technique, cette version du logiciel a egalement demontre que l'interoperabilite 
entre les differentes applications Web Java des partenaires pouvait etre obtenue a Faide de plusieurs 
implementations SOAP : a celle d' Apache, utilisee dans la premiere generation du systeme, s'est 
ajoutee celle de The Mind Electric, mise en ceuvre pour communiquer avec l'annuaire UDDI. Mais 
apres tout, ceci ne change pas encore fondamentalement la situation car nous nous trouvons toujours 
dans un environnement homogene dans lequel les plates-formes technologiques employees 
s'appuient exclusivement sur des environnements Java. 

Ce scenario va etre F occasion de montrer comment les technologies de services Web disposent du 
potentiel necessaire pour permettre un changement drastique en termes d' implementation du systeme 
de reservation sans impacter les systemes d' information existants et les specifications fonctionnelles 
du logiciel developpe dans le cadre du scenario precedent. 

Evolution 

Depuis l'introduction de la seconde version de son service Web de reservation, l'agence de voyages 
SW- Voyages, deja fortement engagee par ailleurs dans les technologies Microsoft pour le reste de son 
systeme d' information, a pris la decision strategique de fonder toutes ses applications sur le socle 
technologique du framework .NET. Dans cette optique, elle a done decide de migrer son systeme de 
reservation actuel Java vers une implementation en technologie .NET et de developper ainsi une 
troisieme generation du logiciel. 

Nouveau systeme 

D'un point de vue fonctionnel, il n'y a aucun changement par rapport a la deuxieme generation du 
systeme de reservation. II s'agit essentiellement d'un changement de plate-forme technologique 
du seul point de vue de l'agence de voyages SW- Voyages. 

En resume, les principaux faits remarques lors de l'etude de la situation du systeme existant sont prin- 
cipalement : 

• l'existence d'une deuxieme generation operationnelle de services Web deja disponibles chez 
chacun des partenaires impliques dans le processus etudie ; 

• la decision strategique de l'agence de voyages de changer de technologie. 

Les orientations prevues par les partenaires, dans le cadre du deploiement de la troisieme generation 
des systemes de reservation, sont les suivantes : 

• capitalisation sur les infrastructures Web deployees lors de la deuxieme phase de deploiement (voir 
la section « Scenario n°2 ») ; 

• minimalisation des impacts du changement sur les systemes deployes chez les partenaires de 
l'agence de voyages. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenaires 
est maintenu sous forme d' installation d' applications Web. 
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Le detail des produits utilises, des choix techniques et du parametrage d' installation est decrit 
chapitre 25 (voir la section « Implementation »). 

Architecture generate 

L' architecture globale de la troisieme generation du systeme de reservation demeure inchangee (voir 
figure 22-8). II convient juste de noter le remplacement du serveur Java Apache Tomcat de SW- Voyages 
par un serveur IIS 5.0 de Microsoft. 

Cinematique des echanges 

La cinematique decrite lors du scenario n°2 s' applique en tous points a celle qui sera mise en ceuvre 
dans ce troisieme scenario. 

Demarche de developpement 

Dans le cadre d'un developpement initial sur le framework .NET, la demarche generate de develop- 
pement du nouveau systeme de reservation est strictement identique a celle qui a ete utilisee dans le 
deuxieme scenario. La seule difference reside dans le fait que les classes manipulees et generees sont 
des classes C# au lieu de classes Java. 

Dans le cas present, il s'agit de la reprise d'une implementation Java anterieure et de sa transposition 
a 1' identique en langage C#. Nous nous placons done dans une optique de migration par portage du 
code existant d'une plate-forme technologique vers une autre plate-forme. 

Migration de ('application Web de SW-Voyages vers le framework .NET 

La migration de cette application Web sera effectuee par un portage manuel du contenu de 1' application 
Java vers une application .NET L application .NET sera decomposed en deux projets : 

• un premier projet de type application Web ASP.NET pour implementer F equivalent de la partie 
cliente de 1' application Java ; 

• un second projet de type service Web ASP.NET pour reprendre la partie serveur de 1' application 

Java. 

La gestion de ces deux projets sera prise en charge par l'environnement de developpement Visual 
Studio.NET 7.0 de Microsoft (MSDE 2002), lequel s'appuie sur le framework .NET 
(version 1 .0.3705). Le deploiement sera realise sur la version limitee du serveur IIS 5.0 de Microsoft, 
integree dans le systeme d' exploitation Windows 2000 Professional. 

Developpement 

Le developpement de la troisieme generation du systeme de reservation n'impacte que la partie 
serveur de l'application Web de SW-Voyages. Les changements, par rapport a la deuxieme genera- 
tion du systeme, sont uniquement d'ordre technique et se revelent tres importants du fait de l'adop- 
tion d'une nouvelle plate-forme technique. En revanche, ils demeurent circonscrits au domaine de 
l'agence de voyages. 
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Application Web de SW-Voyages 

L'arborescence de F application Web de la societe SW-Voyages (repertoire reservation_sw-voyages), 
en depit du changement de plate-forme technologique, demeure tres proche de celle du premier 
scenario, a l'exception des sous-repertoires schemas et services-type qui disparaissent au profit de 
1' application de l'organisation sectorielle SW-Tourisme-XML dont depend Fagence de voyages (voir 
« Scenario n°2 »). Bien entendu, le sous-repertoire WEB-INF disparait pour etre repris dans le second 
projet de type service Web ASP.NET (partie serveur). 

Partie cliente de I 'application Web de SW-Voyages 

Au final, le contenu de la fenetre de Fexplorateur de la solution ASP.NET SW-Voyages doit ressembler 
a celui illustre figure 22-10 : 
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Figure 22-10 

Arborescence de la solution ASP.NET SW-Voyages. 



Partie serveur de I'application Web de SW-Voyages 

L' implementation de cette partie est traitee chapitre 25. 

Le contenu de la fenetre de Fexplorateur de la solution ASP.NET SW-Voyages Reservation doit 
ressembler a celui presente figure 22-1 1 : 
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Figure 22-11 

Arborescence de la solution ASP.NET SW-Voyages Reservation. 



Applications Web des partenaires de SW-Voyages 

Les applications Web Java des trois partenaires de l'agence de voyages restent inchangees. Le 
passage a la technologie Microsoft .NET, realise par SW-Voyages, ne les affecte en rien. L'urbanisme 
du systeme d'information global, mis ail point lors de la deuxieme generation du logiciel de reservation, 
est ainsi preserve. 

Partie cliente des applications Web des partenaires de SW-Voyages 

Cette partie des applications n'est pas consideree. Pour simplifier, nous postulons que les parties 
clientes existantes restent inchangees et n'entrent pas dans le cadre de ce scenario. 

Partie serveur des applications Web des partenaires de SW-Voyages 
L' implementation de ces parties est traitee chapitre 25. 
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Constat 

A partir de ce troisieme scenario, egalement realise sans outils de developpement particuliers, 
excepte l'environnement de developpement Microsoft Visual Studio.NET, nous avons : 

• transpose la deuxieme generation de 1' application simple de reservation de voyages (Java) illustree 
dans le second scenario en une troisieme generation de l'application operationnelle dans l'environ- 
nement d' execution .NET ; 

• maintenu, sans modification, la federation des capacites applicatives (Java) des systemes d' infor- 
mation respectifs des quatre partenaires industriels concernes ; 

• introduit une nouvelle plate-forme technologique (.NET) de maniere non aggressive pour le 
systeme d'information existant de l'agence de voyages, notamment sans effet sur les systemes 
d'information des partenaires de l'agence (sauf mise a jour des balises soapAction) ; 

• conserve, sans modification, F implementation d'annuaire UDDI (Java), introduite dans le 
deuxieme scenario : finalement, cette troisieme maquette met en ceuvre quatre implementations 
differentes du protocole SOAP (deux Java, une C# et une JavaScript). 

De cette nouvelle experience, nous pouvons tirer les enseignements suivants : 

• La mise en ceuvre d'une telle architecture reste toujours relativement simple : le seul element 
nouveau introduit par rapport a 1' architecture presentee dans le deuxieme scenario est la plate- 
forme .NET de Microsoft, associee au serveur HTTP IIS 5.0. 

• Les temps de reponse restent equivalents a ceux que nous avons releves dans le deuxieme scenario. 

• Le remplacement d'une implementation de service Web par une autre, sans necessiter de modifi- 
cation, est confirme : meme lorsque les plates-formes technologiques sont tres differentes, Finter- 
operabilite permet de s'abstraire des contingences propres a ces environnements. 

Cependant, les faiblesses observees dans le deuxieme scenario restent toujours d'actualite et ne sont 
pas reglees par ce changement technologique. 

Scenario n°4 (architecture en processus metier) 

Le troisieme scenario a illustre a quel point l'objectif principal des technologies de services Web, a 
savoir Finteroperabilite entre plates-formes heterogenes, constitue d'ores et deja une realite tangible 
et operationnelle. Cependant, ce type d' architecture synchrone ne permet pas de regler certaines diffi- 
cultes constatees lors de la mise en ceuvre de la premiere generation du systeme et qui demeurent 
d'actualite, apres usage des deux generations suivantes. Les trois premiers scenarios n'ont pas 
apporte de solutions dans le domaine de la gestion fiable du systeme de reservation, de la prise en 
compte de defaillances partielles de Fun ou F autre des partenaires et de la coherence du systeme 
d'information global (transactions). 

Ce dernier scenario est destine a montrer une reponse possible a cette problematique, reponse indis- 
pensable pour permettre la mise en ceuvre d'un systeme de gestion critique. 
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Evolution 



Depuis 1' introduction de la premiere version de son service Web de reservation, l'agence de voya- 
ges SW- Voyages a pu constater une baisse importante des activites manuelles liees au processus de 
reservation dans ses services. Cependant, une part significative de ces activites est induite par le 
nouveau systeme, essentiellement due a des procedures de reconciliation et de redressement avec 
les partenaires. 

Ces procedures sont rendues necessaires du fait des faiblesses deja constatees et inherentes a l'archi- 
tecture technique. En effet, il a ete etabli qu'il manque un systeme de gestion des transactions metier, 
soit synchrone (transactions courtes avec validation a deux phases), soit asynchrone (transactions 
longues avec systeme de compensation). Un constat identique est etabli du cote des partenaires de 

SW- Voyages. 

Les quatre partenaires du systeme de reservation de l'agence de voyages SW- Voyages ont done 
decide de faire evoluer la version initiale par l'integration d'un systeme de gestion transactionnelle 
fiable, tout en maintenant les fonctions existantes, et de developper ainsi une quatrieme generation de 
ce systeme. 

Ce dernier scenario represente en fait une evolution du premier scenario. 

Nouveau systeme 

En resume, les principaux faits remarques lors de 1' etude de la situation du systeme existant sont 
principalement : 

• F existence d'une premiere generation operationnelle de services Web deja disponibles chez 
chacun des partenaires impliques dans le processus etudie ; 

• la presence d'un residu d' activites manuelles qui ne sont pas en relation directe avec le cceur de 
l'activite de SW- Voyages et de ses partenaires. 

Les orientations prevues par les partenaires, dans le contexte du deploiement de la quatrieme generation 
des systemes de reservation, sont les suivantes : 

• capitalisation sur les infrastructures Web deployees lors de la premiere phase de deploiement (voir 
« Scenario n° 1 ») ; 

• integration d'un systeme de gestion des processus metier fiable en mesure de garantir la coherence 
des systemes d'information des partenaires et de limiter aux cas extremes l'utilisation de procedures 
manuelles de reconciliation. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenaires 
est maintenu sous forme d'installation d' applications Web. 

Le detail des produits utilises, des choix techniques et du parametrage d'installation est decrit 
chapitre 26 (voir la section « Implementation »). 
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Architecture generate 

L' architecture globale de la premiere generation du systeme de reservation demeure inchangee (voir 
figure 22-2). II convient juste de noter le remplacement du serveur Java Apache Tomcat de SW- Voya- 
ges et de ses partenaires par un serveur BPEL Orchestration Server de Collaxa. De meme, l'imple- 
mentation SOAP utilisee n'est plus Apache SOAP 2.3.1 mais Apache Axis 1.0 (incorporee dans le 
serveur Collaxa). Pour la societe SW- Voyages, le remplacement du serveur Java Apache Tomcat n'est 
que partiel et ne concerne que la partie serveur de 1' application. En effet, la partie cliente (gestion du 
poste de travail), developpee dans le cadre du premier scenario, est maintenue sur le serveur Tomcat 
(c'est un choix opere arm de limiter les modifications entre les deux versions, et non une obligation). 

Cinematique des echanges 

La cinematique presentee lors du scenario n°l s' applique en tous points a celle qui sera mise en 
ceuvre dans ce quatrieme scenario. 

Demarche de developpement 

La demarche generate de developpement du nouveau systeme de reservation peut etre organisee de la 
maniere suivante : 

1. redaction des schemas XML de description des documents contenus dans les messages SOAP 
echanges entre les quatre partenaires (fichiers d' extension .xsd) ; 

2. generation des classes Java de representation des schemas XML de description des documents 
d' interface des services de reservation (binding Java/XML) ; 

3. redaction des schemas de description des types de donnees complexes echanges lors des invocations 
des services de reservation, propres a chacun des quatre partenaires (fichiers d'extension .xsd) ; 

4. generation des classes Java de representation des schemas XML de description des types de 
donnees complexes renvoyes lors des invocations des services de reservation (binding Java/ 
XML); 

5. redaction des scenarios BPEL des services de reservation, propres a chacun des quatre partenaires 
(fichiers d'extension . jbpel) ; 

6. generation (optionnelle) des classes proxy-services Java a partir des fichiers de description des 
services Web (WSDL) des partenaires (les fichiers produits lors des etapes 7 et 8 pour les parte- 
naires de SW- Voyages doivent avoir ete generes a ce niveau pour pouvoir generer les classes 
proxy-services de SW- Voyages) ; 

7. generation des classes Java executables a partir des scenarios BPEL des services de reservation ; 

8. generation (automatique) des fichiers de description des services Web (WSDL) a partir - des 
scenarios BPEL des services de reservation ; 

9. generation (automatique) des clients de test des services Web produits a partir des fichiers de 
description des services Web (WSDL) generes ; 

10. codage de 1' application Web cliente. 

Comme dans le premier scenario, le dernier point (codage de l'application Web cliente) est traite 
dans ce chapitre avant les neuf points precedents illustres chapitre 26 (application Web serveur). 
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La demarche utilisee ici est legerement differente de celle qui a ete adoptee lors du premier scenario. 
Celle-ci etait axee sur la description initiale de F interface Java du service Web et sur une generation 
en cascade de divers elements : description WSDL du service, classes de proxy-services Java, sque- 
lette d' implementation Java. 

Dans le cas present, F interface du service est decrite par les documents XML que le service est 
susceptible d'emettre et de recevoir lors de Fechange de messages SOAP, de meme que sont decrites 
les structures de donnees metier gerees a travers ces echanges de documents (choregraphie). La 
redaction des scenarios BPEL trouve son equivalence dans la redaction des classes d' implementation 
du premier scenario. Lensemble de ces documents est ensuite utilise pour generer un certain nombre 
d' elements : description WSDL du service, classes de proxy-services Java, classes de liaison 
(binding) Java/XML. 

Developpement 

Le developpement de la quatrieme generation du systeme de reservation introduit des changements 
importants dans la structuration des applications Web des quatre partenaires. Si la partie cliente de 
F application Web de SW- Voyages reste identique, malgre quelques modifications d'ordre technique 
dues a la mise en ceuvre du style d'echange document avec le serveur, la partie serveur de chacune 
des quatre applications Web est completement revue, essentiellement du fait de Fadoption du serveur 
BPEL Orchestration Server de Collaxa. 

Application Web de SW- Voyages 

Larborescence de F application Web (partie cliente de gestion du poste de travail) de la societe SW- 
Voyages (contexte reservation_sw-voyages) reste identique a celle du premier scenario (figure 22-4), 
a Fexception des repertoires schemas et services-type qui ne sont plus utilises. De meme, les sous- 
repertoires classes et 1 ib de WEB- INF ne sont plus utilises car la partie serveur de Fapplication est 
maintenant hebergee par le serveur Collaxa. 

Larborescence de Fapplication Web (partie serveur applicatif) de la societe SW- Voyages (repertoire 
reservation^sw-voyages) est tres differente de celle du premier scenario et se presente done telle que 
Fillustre la figure 22-12. 

L application Web (partie cliente de gestion du poste de travail) est entierement localisee dans le 
repertoire {%TOMCAT_HOME%}\webapps\reservation_sw-voyages du serveur Tomcat. 

L application Web (partie serveur applicatif) est entierement contenue dans le repertoire 
(%COLLAXAJOME%}\cxdk\samples\reservation_sw- voyages du serveur Collaxa. 

Partie cliente de Fapplication Web de SW-Voyages 

La partie cliente de Fapplication Web reste strictement identique, d'un point de vue fonctionnel, a 
celle qui a ete deployee lors du premier scenario. 

Les seuls changements introduits par cette seconde generation se situent a un niveau technique dans 
le code JavaScript et touchent essentiellement la maniere d'invoquer et de recuperer les resultats des 
services Web. 
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Figure 22-12 

Arborescence de V application Web de la societe SW- Voyages (partie serveur). 
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Les communications entre l'application cliente et le serveur de SW- Voyages s'effectuent par Finter- 
mediaire d'echanges de documents XML. Tous les traitements s'executent de maniere asynchrone et 
beneficient de F utilisation sous-jacente des files d'attente JMS mises en ceuvre par le serveur 
Collaxa. Le resultat de F invocation d'un service est renvoye sur sollicitation (polling) du serveur par 
le poste client. La correlation entre la requete initiale et le resultat de celle-ci est assuree par le biais 
de Fidentifiant de conversation renvoye par le serveur dans la reponse a la requete HTTP initiale. 

C'est done la prise en compte de la notion de conversation qui a necessite ces adaptations du code 
JavaScript. Afin de ne pas compliquer ce quatrieme scenario, nous n'avons pas ete au-dela de ce peri- 
metre. En effet, il conviendrait de pousser plus loin Favantage offert par le fonctionnement en mode 
asynchrone, notamment en ajoutant une fonction de persistance locale de Fetat de l'application et des 
conversations en cours avec le serveur (sauvegarde des identifiants des conversations). Cette exten- 
sion de l'application cliente permettrait, en cas d'arret du poste de travail ou d'erreur de l'application, 
de pouvoir redemarrer celle-ci dans Fetat oil elle se trouvait au moment de la perturbation et de 
reprendre la(les) conversation(s) avec le serveur au point d' interruption. 

Une autre adaptation a ete rendue indispensable du fait de la structure de F interface Java implements 
par tous les scenarios BPEL du serveur de Collaxa (voir la section « Developpement » du chapi- 
tre 26). Cette particularite a necessite Feclatement de la classe ReservationService.java de la 
premiere generation du systeme de reservation (voir chapitre 23) en six scenarios BPEL, exposes 
sous la forme d'autant de services Web susceptibles d'etre invoques par des clients externes au 
serveur Collaxa. En fait, Funique service Web de la premiere generation se transforme en six services 
Web dans cette nouvelle generation. 

Le script reservation. js (voir code complet a telecharger sur www.editions-eyrolles.com) est toujours 
localise dans le repertoire {%TOMCATJHOME%}\webapps\reservation_sw-voyages\scripts de l'applica- 
tion cliente. 

Par rapport a la version utilisee dans la premiere version de l'application (www.editions-eyrolles.com), le 
comportement recupere non plus une description de service WSDL (URL fournie par la variable 
RESERVATION_WSDL_URL) mais bien les six descriptions de services WSDL dont les URL sont fournies 
par les variables : 

• RESERVATION_SEARCH_WSDL_URL ; 

• RESERVATION _GETAIR_WSDL_URL ; 

• RESERVATION_GETHOTEL_WSDLJJRL ; 

• RESERVATION_GETCAR_WSDL_URL ; 

• RESERVATION_BOOK_WSDL_URL ; 

• RESERVATION_CANCEL_WSDL_URL 
L affectation initiale de la variable : 



Iva 



r RESERVATION_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/services/ 
ReservationService.wsdl " ; 



est remplacee par : 



Iva 



r RESERVATION_SEARCH_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 
services/Reservation_Search.wsdl " ; 
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var RESERVATION_GETAIR_WSDL_URL - "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 

**services/Reservation_GetAi r.wsdl " ; 

var RESERVATION_GETHOTEL_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 

*-services/Reservation_GetHotel .wsdl " ; 

var RESERVATION_GETCAR_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 

**services/Reservation_GetCar.wsdl " ; 

var RESERVATION_BOOK_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 

**services/Reservation_Book.wsdl " ; 

var RESERVATION_CANCEL_WSDL_URL = "http://www.sw-voyages.com:8080/reservation_sw-voyages/ 

*»services/Reservation_Cancel .wsdl " ; 

De meme, la declaration initiale d' utilisation du service Web Reservati onServi ce (dont la description 
WSDL est situee a Fadresse RESERVATION_WSDL_URL) 

service.useService(RESERVATION_WSDL_URL, "Reservati onService") ; 

est remplacee par une declaration d'utilisation de six services Web : 

service. useService(RESERVATION_SEARCH_WSDL_URL, "Reservati onSearch"); 
service. useService(RESERVATION_GETAIR_WSDL_URL, "Reservati onGetAir"); 
service. useService(RESERVATION_GETHOTEL_WSDL_URL, "Reservati onGetHotel ") ; 
service. useService(RESERVATION_GETCAR_WSDL_URL, "Reservati onGetCar"); 
service. useService(RESERVATION_BOOK_WSDL_URL, "Reservati onBook"); 
servi ce.useService(RESERVATION_CANCEL_WSDL_URL, "Reservati onCancel" ); 

Fonction search_onclick() 

Le script effectue une demande de recherche de disponibilites via 1' invocation de la methode 
i ni ti ateReservati onServi ce_Search exposee par le service Web Reservati onSearch (voir code complet 
a telecharger sur www.editions-eyrolles.com). Cette demande correspond a Faction n°l decrite dans la 
cinematique des echanges (figure 22-3) : 

try { 
var nodes = "<passengers>"+passengers. val ue+"</passengers><from>" 

+f rom. val ue+"</f rom><to>"+to.value+"</to>" ; 
nodes += "<roundTrip>"+roundtrip.val ue+"</roundTrip><departureDay>" 

+departure_day .val ue+"</departureDay>" ; 
nodes += "<departureMonth>"+departure_month. value 

+"</departureMonth><departureYear>" 

+departure_year.value+"</departureYear>" ; 
nodes += "<ar rival Day>"+arrival_day.val ue+"</arri valDayXarri val Mont h>" 

+arrival_month.val ue+"</arri valMonth>" ; 
nodes += "<ar rival Yea r>"+am'va1_year. val ue+"</ar rival Yea rXhotel Requested>" 

+document.al 1 .hotel .checked+"</hotel Requested>" ; 
nodes += "<carRequested>"+document .all .car.checked+"</carRequested>" ; 
service. Reservati onSearch. cal lService(search_callback, 

"initi ateReservati onServi ce_Search" .nodes) ; 
} 

catch (e) { 
alert( "erreur("+e.number+" ) : "+e. description) ; 
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Fonction search_callback(result) 

La recuperation de la prise en compte par le serveur de l'invocation de la methode 
initiateReservationService_Search est realisee par la fonction search_callback( result). 

La fonction arme une horloge (timer) chargee de declencher une interrogation du serveur a intervalles 
reguliers (polling) afin de recuperer le resultat de la prise en charge de la demande de recherche. 
Cette horloge prend en parametre de la fonction search_poll Result l'identifiant de la conversation 
renvoye par l'invocation de la methode (result, raw. text) et utilise parle serveur pour etablir le lien 
avec le resultat de la requete (correlation). Le seuil de declenchement de l'horloge est ici fixe arbitrai- 
rement a quatre secondes. 

t imerl I D=set Interval ("search_poll Result ( ' "+result.raw.text+" ' )" , 4000) ; 

Fonction search_pollResult(conversationID) 

La recuperation du resultat (asynchrone par polling et callback) de l'invocation de la methode 
initiateReservationService_Search est realisee par la fonction search_poll Result (conversationlD) 
via l'invocation de la methode pollReservationService_SearchResult exposee par le service Web 
ReservationSearch (voir code complet a telecharger sur www.editions-eyrolles.com). La requete HTTP 
envoyee au serveur comporte un en-tete SOAP Conti nueHeader qui contient l'identifiant de la conver- 
sation initiee par la requete initiateReservationService_Search (correlation) : 

try { 

var call = new Objectt ) ; 

call .funcName = "poll ReservationService_SearchResult" ; 

cal 1 .SOAPHeader = new ArrayO; 

var header = "<conversationID>" ; 

header += conversationlD; 

header += "</conversationID>" ; 

call .S0APHeader[0] = header; 

service. ReservationSearch. cal lService(search_poll Resul t_call back, cal 1 ) ; 
} 
catch (e) ( 

alertCerreur("+e.number+") : "+e. description) ; 
} 

Fonction search_pollResult_callback(result) 

La recuperation (asynchrone par polling et callback) de la reponse du serveur suite a l'invocation de 
la methode pollReservationService_Search Resul test realisee par la fonction sea rch_poll Resul t_cal 1 - 
back( result). Cette recuperation correspond a la fin de Taction n°8 decrite dans la cinematique des 
echanges (figure 22-3). 

Le resultat est filtre pari' intermediate de la fonction pending_request( result) chargee de verifier si 
le serveur afini de traiter la requete initiateReservationService_Search : 

if (pending_request(result)==true) { 
window. status = "En attente de disponibil ites. . . " ; 
return; 
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Si le serveur repond par une erreur HTTP 500 dont le corps SOAP contient un element Faul t et dont le 
message commence par la chaine de caracteres Request not finished, le traitement est interrompu et 
laisse l'horloge planifier une nouvelle invocation de la methode pol 1 Reservati onServi ce_SearchResul t. 

Sinon, l'horloge est arretee et la fonction enregistre ensuite le numero de reservation communique 
par le serveur de SW- Voyages : 

set Reservati on Id (result. value) ; 

Puis elle precede aussitot a l'invocation de la methode initiateReservationService„GetAir du 
service Web Reservati onGetAir, de la methode initiateReservationService_GetHotel du service 
Web ReservationGetHotel et de la methode initiateReservationService_GetCar du service Web 
Reservati onGetCar. Ces invocations coiTespondent aux actions n os 9, 13 et 17 decrites dans la cinema- 
tique des echanges (figure 22-3) : 

try { 
var service = parent. reservation. service. ReservationGetAir; 
var reservationld = parent . reservation. getReservationldt ) ; 
var node = "<reservationId>"+reservationId+"</reservationId>" ; 
service. cal lService(get_airAvailabil ities_cal 1 back, 

"initiateReservationService_GetAir" .node) ; 
if (document. al 1 .hotel .checked) { 

service = parent. reservation. service. ReservationGetHotel ; 

service.callService(get_hotel Avail abil ities_callback, 
"initiateReservationService_GetHotel" .node) ; 
} 
if (document. al 1 .car. checked) { 

service = parent. reservation. service. ReservationGetCar; 

service. callService(get_car Avail abil ities_cal lback, 
"initiateReservationService_GetCar" .node) ; 



catch (e) { 

alert( "erreur( "+e.number+" ) : "+e. description) ; 
} 

Fonction get_airAvailabilities_callback(result) 

La recuperation de la prise en compte par le serveur de l'invocation de la methode 

initiateReservationService_GetAir est realisee par la fonction get_airAvail abil ities_callback(result). 

La fonction arme une horloge chargee de declencher une interrogation du serveur a intervalles regu- 
liers afin de recuperer le resultat de la prise en charge de la demande de recuperation des disponibili- 
tes aeriennes. Cette horloge prend en parametre de la fonction get_airAvailabilities_poll Result 
l'identifiant de la conversation renvoye par l'invocation de la methode (resul t . raw . text). Le seuil de 
declenchement de l'horloge est ici fixe arbitrairement a quatre secondes. 

timer2 I D=set Interval ("get_airAvailabil ities_poll Resul t( ' "+resul t. raw.text+" ' )" , 4000) ; 

Fonction get_airAvailabilities_pollResult(conversationID) 

La recuperation du resultat (asynchrone par polling et callback) de l'invocation de la methode 

initiateReservationService_GetAirestrealisee par la fonction get_airAvailabilities_poll Resul t( conver- 
sation^) via l'invocation de la methode pollReservationService_GetAirResult exposee par le 
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service Web ReservationGetAir (voir code complet a telecharger sur www.editions-eyrolles.com). La 
requete HTTP envoyee au serveur comporte un en-tete SOAP ContinueHeader qui contient l'identi- 
fiant de la conversation initiee par la requete i ni ti ateReservati onServi ce^GetAi r (correlation) : 

try { 

var call - new Objectt ) ; 

cal 1 .funcName = "poll ReservationService_GetAirResult" ; 

call .SOAPHeader = new ArrayO; 

var header = "<conversationID>" ; 

header += conversationID; 

header += "</conversationID>" ; 

call .SOAPHeader[0] = header; 

service. ReservationGetAir. cal 1 Service ( 
get_ai rAvailabil ities_poll Resul t_call back, cal 1 ) ; 
} 
catch (e) ( 

alert("erreur("+e.number+") : "+e. description) ; 
} 

Fonctionget_airAvailabilities_pollResult_callback(result) 

La recuperation (asynchrone par polling et callback) de la reponse du serveur suite a F invocation de 
la methode pollReservationService_GetAirResult est realisee par la fonction get_ai rAvai labi- 
1 i ti es_pol 1 Resul t_cal 1 back( resul t ). Cette recuperation correspond a la fin de Faction n°12 decrite 
dans la cinematique des echanges (figure 22-3). 

Leresultat est filtre pari' intermediate de la fonction pending_request( result) chargee de verifier si 
le serveur afini de traiter la requete initi ateReservati onService_GetAir : 

if (pending_request(result)==true) { 

window. status = "En attente de disponibilites aeriennes. . . " ; 

return; 
} 

Si le serveur repond par une erreur HTTP 500 (dont le coips SOAP contient un element Faul t et dont le 
message commence par la chaine de caracteres Request not finished), le traitement est interrompu et 
laisse Fhorloge planifier une nouvelle invocation de la methode pol 1 Reservati onServi ce_GetAi rResul t. 

Sinon, Fhorloge est arretee et la fonction construit dynamiquement les tableaux de disponibilites 
aeriennes du cadre avai 1 abi 1 i ti es . html (selection des vols aller et retour), a partir de la deserialisation 
du tableau de disponibilites renvoye par le serveur et recupere de la maniere suivante : 

var availabilities - resul t. raw. getElementsByTagNameC'item") ; 

Fonction get_hotelAvailabilities_callback(result) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction get_ai rAvai 1 a- 
bi 1 ities_cal 1 back (result). 

Fonction get_hotelAvailabilities_pollResult(conversationID) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction get_ai rAvai 1 a- 
bil 1t1es_pol 1 Resul t( conversationID). 
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Elle realise Finvocation de la methode pollReservationService_GetHotel Result exposee par le 
service Web ReservationGetHotel (voir code complet a telecharger sur www.editions-eyrolles.com). 

Fonction get_hotelAvailabilities_pollResult_callback(result) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction 

get_ai rAvail abil ities_pol 1 Resul t_cal 1 back (result). 

Cette recuperation de disponibilites correspond a la fin de Taction n°20 decrite dans la cinematique 
des echanges (figure 22-3). 

Fonction get_carAvailabilities_callback(result) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction get_ai rAvai 1 a- 
bil ities_cal 1 back (result). 

Fonction get_carAvailabilities_pollResult(conversationID) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction get_ai rAvai 1 a- 
bil ities_pol 1 Resul t (con vers at ionID). 

Elle realise Finvocation de la methode poll Res ervationService_GetCar Result exposee par le service 
Web ReservationGetCar (voir code complet a telecharger sur www.editions-eyrolles.com). 

Fonction get_carAvailabilities_pollResult_callback(result) 

Cette fonction est identique (aux noms de methodes et de fonctions pres) a la fonction get_ai rAvai 1 a- 
bil ities_pol 1 Resul t_cal lback( resul t). 

Cette recuperation de disponibilites correspond a la fin de Taction n°16 decrite dans la cinematique 
des echanges (figure 22-3). 

Fonction cancel_onclick() 

La demande d'annulation de recherche de disponibilites est realisee via T invocation de la methode 
1n1t1ateReservat1onServ1ce_Cancel exposee parle service Web ReservationCancel. Cette demande 
correspond a Taction n°21 decrite dans la cinematique des echanges (figure 22-3) : 

try { 

var node = "<reservationId>"+parent. reservation. getReservationlcK ) 

+"</reservationId>" ; 
pa rent. reservation. service. ReservationCancel .call Service ( 
cancel _cal lback, "initiateReservationService_Cancel" ,node) ; 
} 
catch (e) { 

alert("erreur( "+e.number+" ) : "+e. description) ; 
} 

Fonction cancel_callback(result) 

La recuperation de la prise en compte par le serveur de T invocation de la methode 
initiateReservationService_Cancel est realisee par la fonction cancel _ca 11 back (result). 

La fonction arme une horloge chargee de declencher une interrogation du serveur a intervalles 
reguliers afin de recuperer le resultat de la prise en charge de la demande d'annulation de recherche des 



Scenarios d'architectures - Implementation des clients 

Chapitre 22 

disponibilites automobiles. Cette horloge prend en parametre de la fonction cancel_poll Result 
l'identifiant de la conversation renvoye par 1' invocation de la methode (result, raw. text). Le seuil 
de declenchement de 1' horloge est toujours fixe arbitrairement a quatre secondes. 

timer5 I D=set Interval (" cancel _poll Result ( ' "+result.raw.text+" ' )" , 4000) ; 

Fonction cancel_pollResult(conversationID) 

La recuperation du resultat (asynchrone par polling et callback) de 1' invocation de la methode 
initiateReservationService_Cancel est realisee par la fonction cancel „poll Result (conversationID) 
via Finvocation de la methode poll Reservati onService_Cancel Result exposee par le service Web 
ReservationCancel (voir code complet a telecharger sur www.editions-eyrolles.com). La requete HTTP 
envoyee au serveur comporte un en-tete SOAP Conti nueHeader qui contient l'identifiant de la conver- 
sation initiee par la requete initiateReservationService_Cancel (correlation) : 

try { 

var call - new Objectt ) ; 

cal 1 .funcName = " poll ReservationService_CancelResult "; 

call .SOAPHeader = new ArrayO; 

var header = "<conversationID>" ; 

header += conversationID; 

header += "</conversationID>" ; 

call .S0APHeader[0] = header; 

pa rent. reservation. service. ReservationCancel .call Service ( 
cancel_pol 1 Result_call back, cal 1 ) ; 
} 
catch (e) { 

alert("erreur( "+e.number+") : "+e. description) ; 
} 

Fonction cancel_pollResult_callback(result) 

La recuperation (asynchrone par polling et callback) de la reponse du serveur suite a Finvocation de 
la methode pol 1 Reservati onServi ce_Cancel Resul t est realisee par la fonction cancel _pol 1 Resul t_cal 1 - 
back( resul t). Cette recuperation correspond a la fin de Faction n°28 decrite dans la cinematique des 
echanges (figure 22-3). 

Le resultat est filtre pari' intermediate de la fonction pending_request( result) chargee de verifier si 
le serveur afini de traiter la requete initiateReservationService_Cancel : 

if (pending_request(result)==true) { 
window. status = "En attente d'annulation de recherche de disponibilites..."; 
return; 



Si le serveur repond par une erreur HTTP 500, le traitement est arrete et laisse F horloge planifier une 
nouvelle invocation de la methode poll Reservati onService_Cancel Result. 

Sinon, Fhorloge est arretee et la fonction annule le numero de reservation courant : 

setReservationId(null ) ; 
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Fonction book_onclick() 

La demande de reservation des disponibilites selectionnees par l'utilisateur est operee via Pinvoca- 
tion de la methode initiateReservationService_Book exposee par le service Web ReservationBook. 
Cette demande correspond a Taction n°21 decrite dans la cinematique des echanges (figure 22-3) : 

try { 
var nodes = "<reservationId>"+parent. reservation. getReservationlcK ) 

+"</reservationId>" ; 
nodes += "<departureChoice>"+get_selectedChoice_id("departure_choice") 

+"</departureChoice>" ; 
nodes += "<ar rival Choi ce>"+get_selectedChoice_id( "arri val_choice") 

+"</arri valChoice>" ; 
nodes += "<hotelChoice>"+get_selectedChoice_id("hotel_choice") 

+"</hotelChoice>"; 
nodes += "<carChoice>"+get_selectedChoice_id( "car_choice" )+"</carChoice>" ; 
pa rent. reservation. service. ReservationBook. cal lServiceC 
book_callback, "initiateReservationService_Book" .nodes) ; 
} 
catch (e) { 

alert("erreur( "+e.number+" ) : "+e. description) ; 
} 

Fonction book_callback(result) 

La recuperation de la prise en compte par le serveur de 1' invocation de la methode 
initiateReservationService_Book est realisee par la fonction book_call back (result). 

La fonction arme une horloge chargee de declencher une interrogation du serveur a intervalles regu- 
liers afin de recuperer le resultat de la prise en charge de la demande de recuperation des disponibili- 
tes automobiles. Cette horloge prend en parametre de la fonction book_pol 1 Resul t l'identifiant de la 
conversation renvoye par Finvocation de la methode (result. raw. text). Le seuil de declenchement 
de Fhorloge est toujours fixe arbitrairement a quatre secondes. 

timer6 I D=set Interval ("book_pol 1 Resul t( ' "+result. raw.text+" ' )" , 4000) ; 

Fonction book_pollResult(conversationID) 

La recuperation du resultat (asynchrone par polling et callback) de 1' invocation de la methode 
initiateReservationService_Book est realisee par la fonction book_pollResult(conversationID) 
via Finvocation de la methode pollReservationService_BookResult exposee par le service Web 
ReservationBook (voir code complet a telecharger sur www.editions-eyrolles.com). La requete HTTP 
envoyee au serveur comporte un en-tete SOAP ContinueHeader qui contient l'identifiant de la 
conversation initiee par la requete initiateReservationService_Book (correlation) : 

try { 
var cal 1 = new 0bject( ) ; 

cal 1 .funcName = "pollReservationService_BookResult" ; 
cal 1 .SOAPHeader = new ArrayO; 
var header = "<conversationID>" ; 
header += conversationID; 
header += "</conversationID>" ; 
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call .SOAPHeader[0] = header; 

parent.reservation.service.ReservationBook.callService( 
book_poll Resul t_callback,cal 1 ) ; 
} 
catch (e) { 

alert("erreur( "+e.number+") : "+e. description) ; 
} 

Fonctionbook_pollResult_callback(result) 

La recuperation (asynchrone par polling et callback) de la reponse du serveur suite a 1' invocation 
de la methode pollReservationService_BookResult estrealisee par la fonction book_pol 1 Resul t_cal 1 - 
back(result). Cette recuperation correspond a la fin de Taction n°28 decrite dans la cinematique 
des echanges (figure 22-3). 

Leresultat est filtre pari' intermediate de la fonction pending_request( result) chargee de verifier si 
le serveur afini de traiter la requete initiateReservationService_Book : 

if (pending_request(result)==true) { 

window. status = "En attente de confirmation de reservation 
de disponibilites . . . " ; 

return; 
} 

Si le serveur repond par une erreur HTTP 500, le traitement est interrompu et laisse l'horloge planifier 
une nouvelle invocation de la methode poll ReservationServiceJookResult. 

Sinon, l'horloge est arretee et la fonction communique a Futilisateur le numero de reservation definitif 
et lui propose de realiser une autre operation : 

var more = window. confirmC'Votre reservation a ete enregistree sous 
le n°"+parent.reservation.getReservationId( ) 

+"\n(a rappeler dans toute correspondance) .\n\nVoulez-vous effectuer 
une autre reservation ?"); 

Fonction reservation_window_onunload() 

Lorsque Futilisateur decide de quitter l'application de reservation, cela provoque remission de 
l'evenement onunload surl'element body du cadre reservation.html. Fonctionnellement, cela corres- 
pond a une demande d'annulation de la recherche de disponibilites en cours. Ceci est realise via 
1' invocation de la methode initiateReservationService_Cancel exposee par le service Web Reserva- 
tionCancel. Cette demande correspond a Faction n°21 decrite dans la cinematique des echanges 
(figure 22-3) : 

try { 
var node - "<reservationId>"+parent. reservation. getReservationldt ) 

+"</reservationId>" ; 
service. ReservationCancel . cal 1 Service (cancel _ca 11 back, 
"initiateReservationService_Cancel" .node) ; } 
catch (e) { 
alert("erreur("+e.number+") : "+e. description) ; 
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La prise en charge (asynchrone par polling) de la reponse du serveur suite a F invocation de la 
methode initiateReservationService_Cancel est traitee par la fonction cancel_callback( result) 
vue precedemment. 

Fonction soap_error(result) 

Enfin, toutes les fonctions rappelees par callback du comportement WebService de Microsoft appel- 
lent une fonction generique soap_error( resul t) de detection et de signalisation des erreurs (techniques 
et/ou applicatives) remontees lors des echanges via le protocole SOAP. Cette fonction analyse le 
resultat de l'invocation et affiche un message d'erreur en cas d'anomalie : 

function soap_error(result) { 
if (resul t. error) { 
if (pending_request(result)==true) { 

return false; 
} 

var faultCode = resul t.errorDetail .code; 
var faultString = resul t.errorDetail .string; 
var errorString = faultCode + " - " + faultString; 
alertC'A service error occurred : " + errorString); 
return true; 
} 

return false; 
} 

La fonction presente une legere difference par rapport a la version utilisee dans la premiere genera- 
tion du systeme de reservation. Celle-ci est due au fait que le serveur Collaxa repond a une methode 
de type pol 1 Resul t par une erreur HTTP 500 dont le corps SOAP contient un element Faul t et dont 
le message commence par la chaine de caracteres Request not f i ni shed lorsque le traitement declen- 
che par la methode de type initiate n'est pas termine. II ne s'agit done pas d'une veritable erreur 
SOAP et il convient done d'intercepter ces messages, ce qui est realise par la fonction 
pendi ng_request( resul t). 

Fonction pending_request(result) 

La fonction verifie si 1' erreur SOAP renvoyee par le serveur correspond en fait a une requete de type 
i ni ti ate dont le traitement est en cours par le serveur (voir ci-avant) : 

function pending_request(resul t) { 
if (resul t. error) { 
var faultString = resul t.errorDetail .string; 
var faultCode = result .errorDetail .code; 
if ( (faultCode=="nsl:Server. general Exception" && 
faultString. substring(0, 20)=="Request not finished") | 
(faultString. length<20)) { 
return true; 



return false; 
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Differentiation entre requetes pendantes et exceptions 

Dans sa version actuelle (beta 4), le serveur fait bien la difference entre les deux situations lorsque le processus 
appelant est declenche via la console. Un processus en erreur est estampille par une icone particuliere. En revan- 
che, s'il est declenche de I'exterieur (a partir du navigateur par exemple), une exception renvoyee par la methode 
process du scenario appele est traduite comme une reponse a une requete pendante. Ce comportement ne 
permet pas au client de faire la distinction entre une situation d'erreur et un traitement en attente de resultat. II 
devrait done etre modifie dans les prochaines versions du serveur Collaxa. 



Exposition des scenarios sous forme de services Web 

Les scenarios deployes sur un serveur Collaxa peuvent etre invoques de diverses manieres. L'une 
d'entre elles consiste a utiliser l'interface de service Web associe a chacun d'entre eux. En effet, 
chaque scenario BPEL est expose comme un service Web afin de pouvoir etre invoque via l'interface 
du serveur lui-meme ou par un processus externe au serveur. L'interface WSDL est generee automa- 
tiquement lors de l'utilisation du compilateur de scenarios bpelc (voir la section « Construction et 
deploiement des scenarios » du chapitre 26). L'interface WSDL d'un scenario est accessible a partir 
de l'onglet WSDL de la console et est inclus dans le fichier JAR de deploiement du scenario. Depuis la 
version beta 4 du serveur, l'interface est generee en trois versions : 

• une version standard ; 

• une version dite « non encapsulee » (unwrapped) destinee a un usage d' integration dans des 
processus BPEL4WS ; 

• une version WSDL 1.0 destinee a une integration avec des applications BEA Workshop. 

Afin d'invoquer les services Web qui represented les scenarios BPEL de la partie serveur de 1' appli- 
cation de SW- Voyages, il suffit d'utiliser les versions WSDL standards exposees automatiquement 
par le serveur lors du deploiement. 

Normalement, dans le script reservation, js que nous venons de voir, les six variables : 

RESERVATION_SEARCH_WSDL_URL ; 

RESERVATION_GETAIR_WSDL_URL ; 

RESERVATION_GETHOTEL_WSDL_URL ; 

RESERVATION_GETCAR_WSDL_URL ; 

RESERVATION_BOOK_WSDLJJRL ; 

RESERVATION_CANCEL_WSDL_URL 

auraient du pointer vers des URL du serveur Collaxa. 

Cependant, nous avons du contourner une petite difficulte introduite dans cette version beta du 
produit, ce qui nous a amene a telecharger les fichiers WSDL standards du serveur Collaxa vers le 
repertoire {%TOMCAT_HOME%}\webapps\reservation_sw-voyages\services,puis a faire une legere adap- 
tation dans ces descriptions WSDL et a les referencer par les six variables du script JavaScript. 

Dans ce repertoire, le fichier ReservationService.wsdl mis en ceuvre dans la premiere generation du 
systeme de SW- Voyages n'est done plus utilise. II est remplace par six nouveaux fichiers nommes 
(voir code complet a telecharger sur le site des editions Eyrolles) : 

• Reservationjook.wsdl ; 
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• Reservation_Cancel .wsdl (voir code complet a telecharger sur le site des editions Eyrolles) ; 

• Reservation_GetAi r.wsdl (voir code complet a telecharger sur le site des editions Eyrolles) ; 

• Reservation_GetCar.wsdl (voir code complet a telecharger sur le site des editions Eyrolles) ; 

• Reservation_GetHotel .wsdl (voir code complet a telecharger sur le site des editions Eyrolles) ; 

• Reservati on_Search .wsdl (voir code complet a telecharger sur le site des editions Eyrolles). 

La modification realisee dans ces six fichiers est du meme type. Si Ton prend le fichier 
Reservation_Book.wsdl comme exemple, le message : 

|<message name="initiateSoapRequest"> 
<part name=" parameters" element="tns:initiateReservationService_Book"/> 
</message> 

doit etre remplace par : 

|<message name="initiateSoapRequest"> 
<part name="parameters" element="tns:initiate"/> 
</message> 

De meme, 1' element : 

<element name="initiateReservationService_Book"> 
<complexType> 
<sequence> 

<element name="xml BookRequest" type="tns:BookRequest"/> 
</sequence> 
</complexType> 
</element> 

doit etre renomme : 

<element name="initiate"> 
<complexType> 
<sequence> 

<element name="xml BookRequest" type="tns:BookRequest"/> 
</sequence> 
</complexType> 
</element> 

Cette modification devient necessaire car le serveur ne comprend pas le message qu'il recoit du poste 
client si cet element est nomme autrement qu'initiate. Lorsqu'une modification similaire est effectuee 
dans les six descriptions WSDL, tout rentre dans l'ordre. Cette limitation explique egalement la necessite 
d'eclater la description WSDL unique des generations precedentes du systeme de reservation en six 
descriptions dans ce quatrieme scenario (un seul message 1n1 11 ate possible par description WSDL). 

Partie serveur de I'application Web de SW-Voyages 

La majorite des changements introduits par cette quatrieme generation porte sur la partie serveur de 
I'application Web de SW-Voyages. Ceux-ci sont tres importants car ils correspondent a un portage de 
I'application existante sur une nouvelle plate-forme technique. 

L implementation de cette partie est traitee chapitre 26. 



Scenarios d'architectures - Implementation des clients 

Chapitre 22 

Applications Web des partenaires de SW-Voyages 

Comparees au premier scenario, les applications Web deployees par les partenaires sont egalement 
fortement modifiees par rapport aux versions de la premiere generation. 

Ces modifications sont entierement dues a la necessite de porter les applications existantes sur un 
nouveau moteur d' execution qui implemente le systeme de gestion transactionnelle, afin de permettre 
aux services Web des partenaires d'etre enroles an tant que participants aux transactions coordonnees 
par le systeme de SW-Voyages. 

Le developpement de la quatrieme generation du service Web de reservation de SW-Voyages a done 
des effets importants sur les systemes d'information de ses partenaires. Cela ne constitue, bien 
entendu, qu'une situation conjoncturelle, essentiellement imputable au fait que ces implementations 
sont encore tres rares et que les specifications sous-jacentes (BPEL4WS, WS -Coordination et WS- 
Transaction) sont tres recentes et ne font pas encore l'objet d'un consensus entre les principaux 
acteurs dans ce domaine. 

Partie cliente des applications Web des partenaires de SW-Voyages 

Cette partie de 1' application n'est pas consideree. Pour simplifier, nous postulons que la partie cliente 
existante reste inchangee et n'entre pas dans le cadre de ce scenario. 

Partie serveur des applications Web des partenaires de SW-Voyages 
L' implementation de cette partie est traitee chapitre 26. 



Constat 



A partir de ce quatrieme scenario, realise a Faide de la console et des utilitaires du serveur de 
Collaxa, nous avons : 

• transpose la premiere generation de F application de reservation de voyages (Java) illustree dans le 
premier scenario en une quatrieme generation de F application, operationnelle dans Fenvironnement 
d' execution BPEL de Collaxa ; 

• maintenu, mais au prix de modifications techniques (reecriture importante du code Java sans chan- 
gements fonctionnels), la federation des capacites applicatives des systemes d'information respectifs 
des quatre partenaires industriels concernes ; 

• introduit une nouvelle plate-forme technologique (Java) qui offre des capacites de gestion transac- 
tionnelle. 

De cette nouvelle experience, nous pouvons tirer les enseignements suivants : 

• La mise en ceuvre d'une telle architecture est un peu plus complexe que celle de la premiere gene- 
ration, mais demeure encore relativement simple : celle-ci repose entierement sur le serveur BPEL 
Orchestration Server, qui est en fait un moteur d'execution SOAP dote de capacites supplemen- 
taires (gestion de scenarios BPEL, de transactions, de files d'attentes...). 

• Les temps de reponse sont superieurs a ceux constates dans les trois scenarios precedents (en mode 
synchrone). Ceci est vraisemblablement du a differentes causes : la partie cliente peut etre rema- 
niee pour moins sollicker le serveur (polling moins agressif), le potentiel du serveur encore en 
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developpement peut certainement etre ameliore (les performances entre les versions beta 3 et 
beta 4 ont ete sensiblement ameliorees). 

• Le serveur propose une infrastrusture d'echange flable fondee sur une gestion de files d'attente. 
Cette fonction d'infrastructure n'est pas pleinement exploitee dans ce premier exemple car, pour 
des raisons de maniabilite de la demonstration, les quatre agents logiciels applicatifs s'executent 
sur le meme serveur Collaxa. La mise en ceuvre de l'echange fiable est transparente, mais en meme 
temps difficilement parametrable (par exemple, le delai d'expiration de la permanence du message 
dans une file). 

• Le maintien de la coherence entre les systemes d'information des partenaires est assure par la 
gestion transactionnelle (WS -Coordination etWS -Trans action). Dans F etude de cas, les scenarios 
pilotent des business activities. La gestion des situations d' exception est prise en compte sans 
entrainer la necessite, pour le developpeur applicatif, d'ecrire un code complexe et difficile a tester 
ou maintenir. Si l'un des serveurs d' applications tombe en erreur apres que d'autres serveurs ont 
confirme leur reservation, le systeme d'information est maintenu dans un etat stable. Le serveur 
d'applications de SW- Voyages, qui pilote l'agregation de services, est en mesure de compenser 
l'anomalie en demandant l'annulation de la reservation aupres des serveurs qui avaient confirme la 
reservation. Evidemment, ces caracteristiques ne sont pas reellement exploiters dans la mise en 
ceuvre monoserveur Collaxa de l'etude de cas. Avec des modifications mineures, le lecteur qui 
dispose de ressources de calculs reparties peut faire tourner la demonstration sur un environnement 
multimachine et multiserveur. 



Conclusion 

A partir de cette etude de cas evolutive, nous avons : 

• analyse, concu, developpe et deploye une nouvelle application de reservation de voyages, qui 
agrege, via Internet, des services offerts par les systemes d'information des trois partenaires indus- 
tries de l'agence de voyages ; 

• implemente differentes variantes d' architectures techniques possibles : tout d'abord une architec- 
ture statique et synchrone (scenario n°l), puis une architecture dynamique toujours synchrone 
(scenarios n os 2 et 3), qui exploite un annuaire UDDI et enfin une architecture statique mais asyn- 
chrone, structuree en processus metier (scenario n°4) ; 

• exploite differentes plates-formes technologiques (Java et .NET), dont nous avons pu remarquer 
l'interchangeabilite totale dans le cadre de l'architecture repartie synchrone : seules quelques 
legeres adaptations du client (gestion du poste de travail) ont ete necessaires ; 

• mis en ceuvre et verifie l'interoperabilite de differentes implementations du protocole de commu- 
nication SOAP sur HTTP (jusqu'a quatre implementations s'executant en simultane dans le 
scenario n°3) ; 

• illustre une demarche de developpement adaptee a la realisation d'une application Web destinee a 
fonctionner dans le cadre d'une architecture orientee services (AOS). 

Ces variations successives ont montre que les technologies de services Web sont deja totalement 
operationnelles dans le cadre d' architectures avec style d'echange RPC synchrone. L'interoperabilite 
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entre environnements d'execution et plates-formes technologiques heterogenes est acquise. Ceci 
vient essentiellement du fait que les premiers developpements realises par tous les editeurs de 
produits ont ete menes dans ce cadre. 

Cependant, cette forme d' architecture peut se reveler insuffisante, notamment dans Foptique de la 
mise en ceuvre d' applications Web qui federent et agregent des services offerts par plusieurs partenaires. 
La classe d' architecture dont le systeme de reservation de SW- Voyages est une maquette se place 
indubitablement dans cette categorie. 

Nous constatons pour cette categorie Finsuffisance de 1' infrastructure batie exclusivement sur les 
technologies de base (SOAP, WSDL et UDDI) et la necessite de passer a un niveau superieur. II 
s'agit de disposer d' infrastructures qui assurent la fiabilite des echanges, notamment via l'utilisation 
de files d'attente et de communications reposant sur des echanges de documents en mode asyn- 
chrone. Ces applications ont egalement besoin de disposer d'un systeme de gestion de transactions 
(courtes ou longues) qui garantissent la coherence entre les systemes d' information des partenaires 
concernes par les processus metier implemented. Enfin, ces echanges doivent pouvoir prendre place 
dans un contexte securise. 

Une partie de ces services d' infrastructure est prise en charge par les produits qui implemented les 
specifications BPEL4WS, WS -Coordination et WS-Transaction, comme le serveur BPEL de Collaxa 
par exemple (voir scenario n°4). Cependant, il existe encore tres peu d' implementations dans ce 
domaine et les developpements de produits en cours qui se concretiseront dans les mois a venir sont 
cruciaux. Par ailleurs, Finteroperabilite entre ces nouveaux produits devra egalement etre demontree : 
beaucoup de travail en perspective pour le WS-I ! 

Cette etude de cas fonctionnelle et les differentes variantes d' implementation nous ont montre que 
contrairement a certaines idees recues plus ou moins repandues, les possibilites offertes par les tech- 
nologies de services Web sont deja tres importantes et de nombreuses implementations peuvent 
d'ores et deja etre utilisees avec succes et sont operationnelles dans des conditions normales 
d' exploitation : cela se verifie notamment pour des applications dont l'objectif est de « doubler » un 
site Web existant (avec gestion dynamique de contenu ou gestion de transactions) par un service Web 
qui se presente comme un second canal d'acces et qui peut, a terme, releguer le premier au traitement 
des situations d'erreur ou d'exception. 

II n'en reste pas moins vrai que la mise au point d'architectures complexes (dont l'etude de cas est 
une illustration), qui impliquent de nombreux partenaires dans le cadre de processus metier sophisti- 
ques, necessite encore quelques evolutions en termes de specifications et du travail en matiere de 
fiabilisation et d'industrialisation des implementations. Ce processus d' evolution est deja enclenche 
et les produits de cette nouvelle generation de plates-formes commencent a apparaitre sur le marche. 
II est vraisemblable que d'ici a quelques mois, le pay sage dans ce domaine aura beaucoup change et 
que, la aussi, nous disposerons de solutions solides, capables de prendre en charge des architectures 
de services Web de plus en plus elaborees. 



23 



Architecture statique - 
Implementation des services Java 



Le chapitre precedent a permis d'etablir le cadre fonctionnel de F etude de cas et de presenter F imple- 
mentation cliente de F application de reservation. 

Ce chapitre va illustrer une premiere implementation de la partie serveur du service de reservation, 
uniquement realisee a Faide de composants issus de la technologie Java. 

Cette premiere generation du logiciel de reservation correspond au scenario n°l presente dans le 
chapitre 22. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenai- 
res sera realise sous forme d' installation d' applications Web qui viendront s'ajouter aux applications 
existantes deja disponibles dans les systemes d' information des partenaires. 

Produits utilises 

Afin de simplifier la configuration necessaire au fonctionnement de la maquette du nouveau 
systeme de reservation, un seul serveur Java (dans un premier temps) sera employe. Nous avons 
retenu le serveur Apache Tomcat 4.1.12 (projet « Jakarta »), mais bien entendu, les quatre serveurs 
utilises dans le systeme auraient pu tout aussi bien etre de type WebSphere 4.0 ou 5.0, ou encore 
Web Logic 6.1 ou 7.0, ou toute autre solution equivalente... 
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Apache Tomcat 4. 1. 12 

Le serveur d' applications Apache Tomcat 4.1.12 peut etre telecharge a partir de Fadresse http:// 
jakarta.apache.org/builds/jakarta-tomcat-4Melease/v4. 1.1 2. Plus particulierement, le fichier d' installation 
binaire jakarta-tomcat-4. 1.12-LE-jdkl4.zip (version lightweight) peut etre utilise conjointement 
avec le SDK Standard Edition 1.4.1 de Sun Microsystems. 

Dans la suite du chapitre, nous considererons que le serveur d' applications est installe dans le reper- 
toire C:\Tomcat_4.1. 12- LE, sous Windows 2000 Professional par exemple, et ce repertoire seradesigne 
par la variable {£T0MCAT_H0MESS}. 



Variable d'environnement CATALINA HOME 

Si d'autres installations anterieures de Tomcat ont deja ete effectives sur la machine utilisee, il est necessaire de 
verifier que la variable d'environnement du systeme CATALINA_HOME pointe sur le repertoire adequat de Tomcat. 



Sun Microsystems SDK Standard Edition 1.4. 1 

Le SDK Java 2 Standard Edition 1 .4. 1 FCS (First Customer Shipment) de Sun Microsystems est 
accessible a Fadresse http://java.sun.eom/j2se/1.4.1/index.html.he repertoire d' installation C:\Jdk_l. 4. 1-SE 
du SDK sera represente par la variable {%JAVA_H0ME&}. 

Apache SOAP 2.3. 1 

En ce qui concerne le moteur d'execution SOAP, nous avons selectionne la derniere version stable de 
F implementation Apache SOAP (version 2.3.1) d'origine IBM. La encore, nous aurions pu choisir 
d'autres implementations Java du protocole SOAP, comme par exemple le moteur Apache Axis 1.0, 
destine a succeder a celui que nous avons finalement choisi, ou bien F implementation de Hewlett- 
Packard HP-SOAP 2.0. 1. 

Le moteur d'execution Apache SOAP 2.3.1 est accessible a http://xml.apache.Org/dist/soap/version-2.3.1. 
Le repertoire d' installation C : \Soap_2 . 3 . 1 du moteur d'execution SOAP sera represente par la variable 

{%S0AP_H0ME%}. 



Paquetages complementaires de la distribution Apache SOAP 2.3.1 

La distribution Apache SOAP 2.3.1 est incomplete. Pour pouvoir fonctionner, le moteur SOAP necessite la 
presence du paquetage mail.jar de I'API JavaMail de Sun Microsystems et du paquetage activation.jar du Java- 
Beans Activation Framework de Sun Microsystems dans son classpath. 



Sun Microsystems JavaMail 1.2 

L implementation de I'API JavaMail est accessible a http://java.sun.com/products/javamail/index.html. La 
version 1.2 release aete utilisee ici. Le repertoire d'installation C:\JavaMail_1.2 de F implementation 
sera represente par la variable { XMAI L_H0ME%} . 
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Sun Microsystems JavaBeans Activation Framework 1.0.2 

L' implementation de l'API JavaBeans Activation Framework est telechargeable a l'adresse http:// 
java.sun.com/products/javabeans/glasgow/jaf.html. Nous avons utilise la version 1.0.2. Le repertoire 
d' installation C: \Jaf_l .0.2 du framework sera designe par la variable { %JAF_H0ME% } . 

Apache Axis 1.0 

Ce moteur d'execution SOAP de la nouvelle generation Apache n'est pas utilise dans cette etude pour 
son aptitude a gerer le protocole SOAP, mais simplement parce que cette distribution integre le 
produit Web Services Description Language for Java Toolkit, via le paquetage WSDL4J d'origine 
IBM. 

Cette boite a outils constitue une implementation Java, capable de representer et manipuler des 
descriptions de services Web en format WSDL. Elle est susceptible de devenir F implementation de 
reference de la JSR 110 Java APIs for WSDL (voir http://www.jcp.0rg/jsr/detail/1 W.jsp). 

Le produit WSDL4J est aussi disponible, en format source uniquement (CVS), sur le site Open 
Source Projects developerWorks dTBM (voir http://www-124.ibm.com/developerworks/projects/wsdl4j), sous 
licence Common Public License. 

Le moteur d'execution Apache Axis 1.0 est accessible a http://xml.apache.org/dist/axis/1_0. Le repertoire 
d' installation C:\Axis_1.0 du moteur d'execution Axis sera represente par {%AXIS_H0MEX}. 

Microsoft behavior WebService 1.0. 1. 1 120 

Ce composant, propre a l'environnement Internet Explorer (fichier webservice.htc) implemente le 
protocole SOAP en langage JavaScript. De meme, il prend en charge la specification WSDL et peut 
prendre en compte des descriptions de services Web sous ce format. 

Le fichier peut etre directement telecharge du site MSDN de Microsoft a l'adresse http://msdn.micm- 
soft.com/library/default.asp?url=/workshop/author/webservice/overview.asp. 

Parametrage des produits 

Ann de faire aboutir les requetes HTTP adressees aux quatre domaines (www. sw- voyages . com, www. sw- 
air.com, www.sw-hotels.com et www.sw-voitures.com) sur l'unique serveur d' applications Web 
Tomcat, il est necessaire d'effectuer deux reglages prealables : 

• modifier le fichier Host du systeme d'exploitation en y ajoutant les lignes suivantes (fichier 
C:\winnt\system32\drivers\etc\hosts sous Windows 2000, par exemple) : 

127.0.0.1 www.sw-voyages.com 

127.0.0.1 www.sw-hotels.com 

127.0.0.1 www.sw-air.com 

127.0.0.1 www.sw-voitures.com 
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• modifier le fichier de configuration de Tomcat en y ajoutant autant d' notes virtuels que de 
nouveaux domaines pris en charge (fichier {%T0MCAT_H0ME%}\conf \server.xml sous Windows 2000, 
par exemple) : 

Definition de l'hote viiluelwww.sw-voyages.com : 

<Host name="www.sw-voyages.com" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw- voyages" docBase="reservation_sw- voyages" 
debug="0" reloadable="false" crossContext="fal se"> 
< Logger cl a ssName=" org. apache. catal ina . logger. FileLogger" 
prefix="reservation_sw-voyages_log. " suffix=" .txt" timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote viituelwww.sw-air.com : 

<Host name="www.sw-air.com" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-ai r" docBase="reservation_sw-air" 
debug="0" reloadable="false" crossContext="false"> 
< Logger cl a ssName=" org. apache. catal ina. logger. FileLogger" 
prefix="reservation_sw-ai r_log. " suffix=" .txt" timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote virtuel www. sw-hotel s . com : 

<Host name="www.sw-hotels.com" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-hotels" docBase="reservation_sw- hotels" 
debug="0" reloadable="false" crossContext="fal se"> 
< Logger cl a ssName=" org. apache. catal ina. logger. FileLogger" 
prefix="reservation_sw- hotel s_log. " suffix=" .txt" timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote virtuel www.sw-voitures.com : 

<Host name="www.sw-voitures.com" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-voitures" docBase="reservation_sw-voitures" 
debug="0" reloadable="false" crossContext="fal se"> 
< Logger cl a ssName=" org. apache. catal ina. logger. FileLogger" 
prefix="reservation_sw-voitures_log. " suffix=" .txt" timestamp="true"/> 
</Context> 
</Host> 

Par ailleurs, afin de pouvoir utiliser l'outil d' administration du moteur d' execution Apache SOAP, il 
convient de declarer son contexte dans l'hote virtuel par defaut de Tomcat (1 ocal host) de la maniere 
qui suit : 

<Context path="/soap" docBase="{%SOAP_HOME%)\webapps\soap" 

debug="0" reloadable="fal se" crossContext="false"> 

< Logger cl as sName=" org. apache. catal ina. logger. File Logger" 
prefix="soap_log. " suffix=" .txt" timestamp="true"/> 
</Context> 



Architecture statique - Implementation des services Java 

Chapithe 23 

Avant de pouvoir utiliser l'outil d' administration du moteur d'execution Apache SOAP, il est neces- 
saire de realiser quatre autres actions pour rendre le deploiement du moteur SOAP effectif : 

1. creer un repertoire lib sous le repertoire {%SOAP_HOMEJ!}\webapps\soap\WEB-INF ; 

2. y copier le fichier {%S0AP_H0ME%}\1 ib\soap. jar ; 

3. y copier le fichier {%MAI L„HOME%}\mail .jar ; 

4. y copier le fichier {%JAF_HOME%}\activation. jar. 

Le deploiement des produits utilises doit etre poursuivi ainsi : 

1. Deploiement du moteur d'execution SOAP dans les quatre applications : 

- copier le fichier {XSOAP_HOME%}\lib\soap. jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-ai r\WEB-INF\l ib ; 

- copier le fichier {%S0AP_H0ME%}\l1b\soap. jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw- hotel s\WEB-INF\lib ; 

- copier le fichier {XSOAP_HOME£}\lib\soap.jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-voitures\WEB-INF\l ib ; 

- copier le fichier {XSOAP_HOMEft}\lib\soap.jar dans le repertoire {3iT0MCAT_H0ME%}\webapps\ 
reservation_sw-voyages\WEB-INF\l ib. 

2. Deploiement de F implementation JavaMail dans les quatre applications : 

- copier le fichier (SSMAIL_HOME%}\mail .jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-ai r\WEB-INF\l ib ; 

- copier le fichier (SSMAIL_HOME%}\mail .jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-hotels\WEB-INF\l ib ; 

- copier le fichier {%MAI L_HOME%}\mail .jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-voitures\WEB-INF\l ib ; 

- copier le fichier (SSMAIL_HOME%}\mail .jar dans le repertoire {!6T0MCAT_H0ME£}\webapps\ 
reservation_sw-voyages\WEB-INF\l ib. 

3. Deploiement de F implementation JavaBeans Activation Framework dans les quatre applications : 

- copier le fichier {%JAF_HOME%}\activation.jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-ai r\WEB-INF\l ib ; 

- copier le fichier {%JAF_H0ME%}\ activation. jar dans le repertoire {%TOMCATJHOME%}\webapps\ 
reservation_sw-hotels\WEB-INF\l ib ; 

- copier le fichier {%JAF_H0ME%}\ activation. jar dans le repertoire {&TOMCAT_HOME%}\webapps\ 
reservation_sw-voitures\WEB-INF\l ib ; 

- copier le fichier {MAF_H0ME%}\ activation. jar dans le repertoire {&TOMCAT_HOME%}\webapps\ 
reservation_sw-voyages\WEB-INF\l ib. 

4. Deploiement de F implementation Web Services Description Language for Java Toolkit dans 
Fapplication reservation_sw-voyages : 

copier le fichier {«AXIS_H0ME%}\1 ib\wsdl4j .jar dans le repertoire {%TOMCAT_HOME%}\webapps\ 

reservation_sw-voyages\WEB-INF\l ib. 
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5. Deploiement du comportement WebService de Microsoft dans l'application reservation^sw- 
voyages : 

copier le fichier webservice.htc telecharge du site Microsoft dans le repertoire 

{%TOMCAT_HOME%}\webapps\reservation_sw-voy ages \ scripts. 

L'arborescence des applications Web deployees dans le serveur d' applications Tomcat est representee 
figure 23-1. 
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Figure 23-1 

Arborescence des applications Web deployees dans le serveur Tomcat. 



Enfin, sous le repertoire WEB-INF des quatre nouveaux domaines, un fichier web.xml dont le contenu 
est le suivant doit etre ajoute : 

<?xml version="1.0" encoding="IS0-8859-l"?> 
<!D0CTYPE web-app 

PUBLIC "-//Sun Microsystems, Inc. //DTD Web Application 2.3//EN" 

"http://java.sun.com/dtd/web-app_2_3.dtd"> 
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<web-app> 
<servlet> 

<servlet-name> rpcrouter </servlet-name> 

<servlet-class> 
org. apache. soap. server. http.RPCRouterServlet 

</servlet-class> 
</servlet> 
<servlet-mapping> 

<servlet-name> rpcrouter </servlet-name> 

<url -pattern> /servlet/rpcrouter/* </url -pattern> 
</servlet-mapping> 
<mime-mapping> 

<extension>xml</extension> 

<miine-type>text/xnil</minie-type> 
</mime-mapping> 
<mime-mapping> 

<extension>xsd</extension> 

<mime-type>text/xml</mime-type> 
</mime-mapping> 
<mime-mapping> 

<extension>wsdl</extension> 

<miine-type>text/xnil</mime-type> 
</mime-mapping> 
</web-app> 

Cet ajout permet au serveur Tomcat de servir correctement les requetes HTTP pour les fichiers dont 
les extensions sont explicitement declarees. Ce fichier doit etre cree sous les repertoires : 

• [%T0MCAT_H0ME%}\webapps\reservat1on_sw-a1r\WEB-INF ; 

• {U0MCAT_H0ME3S}\webapps\reservatiori_sw-hotels\WEB-INF ; 

• {UOMCAOOME%}\webapps\reservation_sw-voitures\WEB-INF ; 

• {U0MCAT_H0ME2}\webapps\reservation_sw-voyages\WEB-INF. 

Pour F application Web de SW- Voyages, il faut ajouter dans le fichier web . xml correspondant la prise 
en charge de F extension htc propre au comportement WebService de Microsoft : 

<mime-mapping> 

<extension>htc</extension> 

<mime-type>text/x-component</mime-type> 
</mime-mapping> 

Developpement 

Le developpement du systeme de reservation, du cote serveur, necessite le developpement et le 
deploiement d'une nouvelle application Web, implemented sous la forme d'un service Web, par 
chacun des quatre partenaires du systeme. Ce developpement est realise selon la demarche exposee 
au chapitre 22 (voir Scenario n°l). 
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Application Web de SW-Voyages 

L'arborescence de 1' application Web de la societe SW-Voyages (contexte reservation_sw-voyages) se 
presente done telle que l'illustre la figure 23-2 : 
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Figure 23-2 

Arborescence de I 'application Web de la societe SW-Voyages. 

L' application complete (partie cliente et partie serveur) est entierement localisee dans le repertoire 
{%T0MCAT_H0ME%}\webapps\reservat1on_sw- voyages du serveur Tomcat. 



Partie serveur de /'application Web de SW-Voyages 

La partie serveur de F application Web de SW-Voyages est entierement realisee sous forme de classes 
Java. Elle ne fait pas appel a la technologie des servlets car F utilisation du protocole HTTP est prise 
en charge directement par le behavior WebService de Microsoft. 

Interface Java du service Web 

Selon la demarche de developpement decrite precedemment, la premiere etape consiste a definir et a 
rediger la classe d' interface Java qui va permettre d'exposer le nouveau service de reservation mis en 
place par la centrale de reservation SW-Voyages (classe IReservationService.java, localisee dans le 
repertoire {%TOMCAT_HOME$}\webapps\reservation_sw- voyages \WEB- IN F\cl asses \com\swvoyages\ reser- 
vation). Cette classe (Telechargez le code source sur www.editions-eyrolles.com) comporte Fensemble 
des methodes qui seront exposees et accessibles a la partie cliente de la nouvelle application Web de 
SW-Voyages, via le comportement WebService de Microsoft : 

• La methode search permet a la partie cliente de communiquer au serveur de SW-Voyages les 
caracteristiques du voyage souhaitees par Futilisateur final. Cette methode est activee dans Faction 
n°l decrite dans la cinematique du processus (figure 22-3). 
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• La methode book est utilisee pour confirmer au serveur de SW- Voyages le souhait de reservation de 
l'utilisateur final. Cette methode est declenchee par Faction n°21 decrite dans la cinematique du 
processus (figure 22-3). 

• La methode cancel constitue le pendant de la methode book decrite precedemment. Elle est utilisee 
pour informer le serveur de SW- Voyages du souhait d'annulation de l'utilisateur final. Cette 
methode est egalement declenchee par Taction n°21 decrite dans la cinematique du processus 
(figure 22-3). 

• La methode getAi rAvai 1 abi 1 i ti es permet a Fapplication cliente de recuperer les disponibilites de 
reservation aerienne et de les afficher a destination de l'utilisateur. Cette methode est activee par 
Faction n°9 decrite dans la cinematique du processus (figure 22-3). 

• La methode getCa rAvai labilities permet a Fapplication cliente de recuperer les disponibilites de 
reservation automobile et de les afficher a destination de l'utilisateur. Cette methode est activee par 
Faction n°13 decrite dans la cinematique du processus (figure 22-3). 

• La methode getHotel Avai 1 abi 1 i ti es permet a Fapplication cliente de recuperer les disponibilites 
de reservation hoteliere et de les afficher a destination de l'utilisateur. Cette methode est activee 
par Faction n°17 decrite dans la cinematique du processus (figure 22-3). 

Cette classe d'interface Java definit ainsi six methodes d'interface qui seront accessibles a travers le 
service Web qui Fencapsulera. 

Generation de la description WSDL du service Web abstrait 

A partir de cette classe d'interface, il est maintenant possible de generer le fichier de definition du 
service Web (WSDL) de reservation. Les possibilites des generateurs sont tres variables : les plus 
frustres permettent de ne generer qu'un seul fichier, d'autres sont plus sophistiques et offrent la 
possibilite de generer plusieurs fichiers distincts (point d'acces du service, description du service 
abstrait, description du schema de donnees). Pour cet exemple, nous allons utiliser une description 
en fichiers distincts. Dans le cas present, ces trois fichiers ont ete rediges et non pas generes par un 
outil. 

La plupart des plates-formes de developpement disposent d'un generateur de descriptions WSDL. 
Dans le cadre de ce scenario, nous n'en disposons pas car nous n'utilisons pas d'environnement de 
developpement particulier. Des environnements tels que le WSTK d'IBM (outil java2wsdl ), Glue de 
The Mind Electric (outil Java2WSDL) ou WASP Server for Java de Systinet (outil Java2WSDL), par 
exemple, peuvent etre utilises dans ce but. 

La description du service abstrait de la centrale de reservation SW- Voyages (fichier ReservationSer- 
vice-interface.wsdl, localise dans le repertoire {XTOMCAT„HOME%}\webapps\reservation_sw-voyages\ 
services-type) est representee dans le code source que vous pouvez telecharger sur www.editions- 
eyrolles.com. 

On reconnait dans ce fichier la description des messages echanges, le type de port unique qui decrit 
les six operations associees aux six methodes de F interface Java precedente et enfin la liaison au 
protocole SOAP, le seul admis pour ce service de reservation. 
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Definition du schema associe au service Web abstrait 

Les structures de donnees necessaires au fonctionnement de ce service sont importees via la refe- 
rence au schema de donnees correspondant (balise import). La description du schema de donnees 
(fichier ReservationService-interface.xsd, localise dans le repertoire {%TOMCAT_HOMEI}\webapps\ 
reservation_sw-voyages\schemas) presente les elements suivants (telechargez le code source sur 
www.editions-eyrolles.com) : 

• definition d'un tableau de disponibilites aeriennes renvoye par la methode getAi rAvan 1 abil ities 
(voir la liste des messages associes a cette methode dans la description du service abstrait : fichier 
ReservationService-interface.wsdl) ; 

• definition d'un element du tableau de disponibilites aeriennes renvoye par la methode getAi r- 
Availabil ities ; 

• definition d'un tableau de disponibilites automobiles renvoye par la methode getCarAvai 1 abi 1 i - 
ties (voir la liste des messages associes a cette methode dans la description du service abstrait : 
fichier ReservationService-interface.wsdl) ; 

• definition d'un element du tableau de disponibilites automobiles renvoye par la methode getCar- 
Avai 1 abil ities ; 

• definition d'un tableau de disponibilites hotelieres renvoye par la methode getHotel Avai labili- 
ties (voir la liste des messages associes a cette methode dans la description du service abstrait : 
fichier ReservationService-interface.wsdl) ; 

• definition d'un element du tableau de disponibilites hotelieres renvoye par la methode getHotel - 
Avai 1 abi 1 ities. 



Description WSDL de implementation du service Web 

II reste a decrire le point d'acces au service concret de reservation sur Internet, propose par SW- Voya- 
ges. La description du point d'acces au service (fichier ReservationService.wsdl, localise dans le 
repertoire {£TOMCAT_HOME%}\webapps\reservation_sw-voyages\services) se presente ainsi : 

<?xml version="1.0" encoding="IS0-8859-l"?> 
definitions 

name="ReservationService" 

t a rgetNamespace=" http://www.sw- voyages. com: 8080/ reservati on_sw- 

voyages/services/ReservationService" 

xmlns:tns=" http://www.sw- voyages .com: 8080/ reservati on_sw- 

voyages/services/ReservationService" 

xmlns : interf a ce=" http://www.sw- voyages. com: 8080/ reservati on_sw- 
voy ages /services -type/ Reservati onService- interface" 

xmlns :soap=" http://schemas.xml soap.org/wsdl /soap/" 

xmlns=" http://schemas.xml soap.org/wsdl /"> 

<import namespa ce=" http://www.sw- voyages. com: 8080/ reservati on_sw- 
voyages/services-type/Reservati onService- interf ace" 

1 oca tion=" http://www.sw- voyages. com: 8080/reservati on_sw- voyages/servi ces - 
type/Reservati onService- interf ace. wsdl"/> 
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<service name="ReservationService"> 
<port bi ndi ng= " interf ace :ReservationSer vice" name="ReservationService"> 
<soap:address 
1 ocation= "http://www.sw- voyages. com: 8080/reservati on_sw- 
voyages/servlet/rpcrouter"/> 
</port> 
</service> 
</definitions> 

On reconnait ici deux balises importantes : la balise import qui reference la description de service 
abstrait generee precedemment et la balise service qui fournit le point d'acces reel au service (attribut 
1 ocation de la balise address) accessible par le protocole SOAP. 

Generation du squelette et implementation du service Web 

La definition WSDL du service Web de reservation est maintenant complete. A partir de cette defini- 
tion, nous pouvons maintenant generer un squelette d' implementation Java du service (skeleton) que 
nous pourrons ensuite completer selon nos besoins. Ce squelette implementera la classe d'interface 
Java definie au depart. 

Cette classe d'implementation du service Web (fichier ReservationService. java, localise dans le reper- 
toire {&TOMCAT_HOME%}\webapps\reservation_sw-voy ages \WEB- I NF\cl asses \com\swvoyages\ reservation 
comporte les methodes suivantes (telechargez le code source sur www.editions-eyrolles.com) : 

• search : invoque successivement les trois services Web afin d'obtenir la reponse des partenaires. 
L' invocation de cette methode est le resultat de Taction n°l decrite dans la cinematique des 
echanges (figure 22-3) et declenchee par le script reservation, js presente chapitre 22. Cette 
invocation provoque 1' activation de la methode equivalente a destination des implementations 
des serveurs SW-Air, SW-H6tels et SW-Voitures. Ces dernieres invocations correspondent aux 
actions n°2, 4 et 6 decrites dans la cinematique des echanges. Les numeros de reservation, 
renvoyes par ces trois serveurs, sont ensuite enregistres localement, ce qui correspond a la fin 
des actions n°3, 5 et 7. 

• book : invoque successivement les trois services Web afin d'obtenir la reponse des partenaires. 
Linvocation de cette methode est le resultat de Taction n°21 decrite dans la cinematique des 
echanges (figure 22-3) et declenchee par le script reservation, js. Cette invocation provoque 
T activation de la methode equivalente a destination des implementations des serveurs SW-Air, 
SW-H6tels et SW-Voitures. Ces dernieres invocations correspondent aux actions n°22, 24 et 26 
decrites dans la cinematique des echanges. Les trois serveurs renvoient ensuite leurs reponses 
respectives, ce qui correspond a la fin des actions n°23, 25 et 27. 

• cancel : invoque successivement les trois services Web afin d'obtenir la reponse des partenaires. 
Linvocation de cette methode est le resultat de Taction n°21 decrite dans la cinematique des 
echanges (figure 22-3) et declenchee par le script reservation, js. Cette invocation provoque 
T activation de la methode equivalente a destination des implementations des serveurs SW-Air, 
SW-H6tels et SW-Voitures. Ces dernieres invocations correspondent aux actions n°22, 24 et 26 
decrites dans la cinematique des echanges. Les trois serveurs renvoient ensuite leurs reponses 
respectives, ce qui correspond a la fin des actions n°23, 25 et 27. 
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• getAirAvai labilities : invoque le service Web du partenaire de reservation aerienne afin 
d'obtenir ses disponibilites. L'invocation de cette methode est le resultat de Taction n°9 decrite 
dans la cinematique des echanges (figure 22-3) et declenchee par le script reservation, js. 
Cette invocation provoque 1' activation de la methode equivalente a destination du serveur 
SW-Air qui correspond a Taction n°10 decrite dans la cinematique des echanges. Le serveur 
SW-Air renvoie ensuite ses disponibilites (action n°ll), lesquelles sont enfin retournees au 
navigateur (action n°12). 

• getCarAvai labilities : invoque le service Web du partenaire de reservation automobile afin 
d'obtenir ses disponibilites. L'invocation de cette methode est le resultat de Taction n°13 decrite 
dans la cinematique des echanges (figure 22-3) et declenchee par le script reservation, js. Cette 
invocation provoque T activation de la methode equivalente a destination du serveur SW-Voitures 
qui correspond a Taction n°14 decrite dans la cinematique des echanges. Le serveur SW-Voitures 
renvoie ensuite ses disponibilites (action n°15), lesquelles sont enfin retournees au navigateur 
(action n°16). 

• getHotel Avail abilities : invoque le service Web du partenaire de reservation hoteliere afin 
d'obtenir ses disponibilites. L'invocation de cette methode est le resultat de Taction n°17 decrite 
dans la cinematique des echanges (figure 22-3) et declenchee par le script reservation, js. Cette 
invocation provoque T activation de la methode equivalente a destination du serveur SW-H6tels qui 
correspond a Taction n°18 decrite dans la cinematique des echanges. Le serveur SW-H6tels 
renvoie ensuite ses disponibilites (action n°19), lesquelles sont enfin retournees au navigateur 
(action n°20). 

Par ailleurs, la classe d' implementation du service Web presente des methodes generiques particulieres : 

• invoke : il s'agit d'une methode d'invocation generique du service Web d'un partenaire. La 
methode encapsule les appels a TAPI de T implementation Apache SOAP. 

• GetServiceAccessPoint : cette methode recupere TURL du point d'acces au service Web d'un 
partenaire a partir de la description WSDL de son implementation. La methode fait appel a TAPI 
WSDL4J d'IBM presente dans le produit Apache Axis. 

• getSchemaNamespace : cette methode est chargee de la recuperation de Tespace de noms associe au 
service Web d'un partenaire a partir de la description WSDL de son implementation. La methode 
fait aussi appel a TAPI WSDL4J d'IBM. 

• getServi ceDef i ni ti on : cette methode a pour objet de recuperer la definition de service associee au 
service Web d'un partenaire a partir de la description WSDL de son implementation. La methode 
utilise egalement TAPI WSDL4J d'IBM. 

La methode getSOAPMappingRegistry prend en charge la declaration des mappers necessaires a la 
conversion des types complexes AirAvai lability, CarAvai lability et Hotel Avail ability. Ceux-ci 
utilisent les services de serialisation/deserialisation de la classe generique BeanSerializer.java 
presente dans T implementation Apache SOAP : 

I private synchronized SOAPMappingRegistry getSOAPMappingRegistry( ) 
throws ReservationException { 
if (smr==nul 1 ) { 



Architecture statique - Implementation des services Java 

Chapitre 23 

smr = new SOAPMappingRegistry( ) ; 
BeanSerial izer bs = new BeanSerial izer( ) ; 

smr. mapTypes( Constants. NS_URI_SOAP_ENC, 
new QNametgetAi rSchemaNamespace( ) , "Ai rAvailabil ity") , 
AirAvail abil ity. class, bs, bs); 
smr. mapTypes( Constants. NS_URI_SOAP_ENC, 
new QName(getCarSchemaNamespace( ) , "CarAvailabil ity") , 
CarAvailabil ity. class, bs, bs); 
smr. mapTypes( Constants. NS_URI_SOAP_ENC, 
new QName(getHotelSchemaNamespace( ) , "Hotel Availabil ity") , 
Hotel Availabil ity .cl ass , bs, bs); 
} 

return smr; 
} 

Enfin, il faut noter la presence dans ce programme des URL des definitions WSDL des trois imple- 
mentations de services Web des partenaires qui seront utilises pour mettre en ceuvre le processus 
metier de reservation de SW- Voyages. Ces URL sont referencees ici de maniere statique, mais 
pourraient etre externalisees dans un fichier de configuration du service Web : 

/* 

* Point d'acces a la description WSDL du service de 

* reservation aerienne. 
*/ 

private static String AIR_SERVICE_WSDL_ACCESS_POINT = "http://www.sw- 
air.com:8080/reservation_sw-air/services/ReservationService.wsdl" ; 

/* 

* Point d'acces a la description WSDL du service de 

* reservation automobile. 
*/ 

private static String CAR_SERVICE_WSDL_ACCESS_POINT = "http://www.sw- 
voi tures.com: 8080/ reservation_sw-voitures/services/ReservationService.wsdl" ; 

/* 

* Point d'acces a la description WSDL du service de 

* reservation hoteliere. 
*/ 

private static String HOTEL_SERVICE_WSDL_ACCESS_POINT = "http://www.sw- 
hotels. com :8080/reservation_sw- hotel s/services/ReservationService.wsdl" ; 

Deploiement du service Web 

Une fois la classe d' implementation du service Web ecrite, il est necessaire de la deployer a destina- 
tion du moteur d' execution Apache SOAR Pour cela, il nous faut utiliser Foutil d' administration 
fourni avec ce moteur, accessible a l'adresse http://localhost:8080/soap/admin/index.html. Lecran de saisie 
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des informations necessaires au deploiement du service est affiche par un clic sur le bouton Deploy, 
visible figure 23-3. 
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Figure 23-3 

Deploiement du service de reservation de la societe SW- Voyages. 



Les informations a saisir dans cet ecran sont : 

• 1'identifiant du service: ici urn:ReservationService, e'est par cet identifiant que le moteur 
d'execution SOAP fera le lien avec la classe d'implementation du service ; 

• la portee du service (Request, Session ou Appl 1 cation) : ici, la portee est 1' application, e'est-a-dire 
que la classe sera instantiee une seule fois, lors de sa premiere invocation ; 

• les noms des methodes de la classe d'implementation exposees (separes par un caractere espace) : 
les methodes book, cancel, getAi r Avail abil ities, getCarAvail abilities, get Hotel Avail abil ities 
et search qui sont exposees dans notre exemple ; 

• le nom qualifie de la classe d'implementation Java (invisible figure 23-3) : com. swvoyages . reser- 
vation. ReservationService ; 
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le nombre de correspondances de types (Type mappings) utilisees par le service (invisible 
figure 23-3) : six correspondances utilisees au total (voir ci-apres) ; 

Trois correspondances de types Navigateur/serveur SW-Voyages 



N° Caracteristiques Valeurs 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http :/ /www. sw- voyages. com: 8080/ res ervation_sw- voyages/ 
schemas/ReservationSer vice -schema 


Nom de partie du schema 


Ai rAvailabi 1 ity 


1 Nom qualifie de la classe Java associee 
a cette partie 


com.swvoyages.reservation.AirAvailabil ity 


Nom qualifie de la classe Java de seria- 
lisation Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de dese- 
rialisation XML vers Java 


org. apache. soap. encoding. soapenc.BeanSerializer 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: // www. sw- voy a ges.com: 8080 /reservation_sw- voyages/ 
schemas/ReservationService-schema 


Nom de partie du schema 


CarAvailabil ity 


2 Nom qualifie de la classe Java associee 
a cette partie 


com.swvoyages.reservation.CarAvailabil ity 


Nom qualifie de la classe Java de seria- 
lisation Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de dese- 
rialisation XML vers Java 


org. apache, soap. encoding. soapenc.BeanSerializer 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: // www. sw- voy a ges.com: 8080 /reservation_sw- voyages/ 
schemas/ReservationService-schema 


Nom de partie du schema 


HotelAvailabil ity 


3 Nom qualifie de la classe Java associee 
a cette partie 


com. swvoyages. reservation. Hotel Avail abil ity 


Nom qualifie de la classe Java de seria- 
lisation Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de dese- 
rialisation XML vers Java 


org. apache, soap. encoding. soapenc.BeanSerializer 
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Trois correspondances de types 


serveur SW-Voyages/serveurs partenaires 


N° Caracteristiques Valeurs 


1 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: //www. sw-a ir.com: 8080/ res ervation_sw- air/ schema s/ 
ReservationService-schema 


Nom de partie du schema 


Ai rAvailabil ity 


Norn qualifie de la classe Java associee a cette 
partie 


com. swvoy ages, r ese r va t i on. Ai rAvailabil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. en coding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. encoding. soapenc.BeanSerializer 


2 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


h ttp :/ /www. sw- voi t u res. com : 8080 /reservation_sw-voitii res/ 
s chema s / Res ervationSer vice -schema 


Nom de partie du schema 


CarAvailabil ity 


Nom qualifie de la classe Java associee a cette 
partie 


com. swvoy ages. r ese r vat ion. CarAvailabil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deserialisa- 
tion XML vers Java 


org. apache. soap. encoding. soapenc.BeanSerializer 


3 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: //www. sw- hotels. com: 8080/ reservation_sw- hotels/ 
schemas /ReservationService-schema 


Nom de partie du schema 


Hotel Avail abil ity 


Nom qualifie de la classe Java associee a cette 
partie 


com. swvoy ages. r ese r vat ion. Hotel Avail abil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. en coding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. en coding. soapenc.BeanSerializer 



Lorsque toutes ces informations necessaires au deploiement du service de reservation ont ete saisies, 
il suffit d'appuyer sur le bouton standard Depl oy (invisible figure 23-3). Si le service est correctement 
deploye, le message « Service urn:ReservationService deployed. » apparait dans la console. 

Pour achever le deploiement, il ne nous reste plus qu'a copier le fichier de serialisation Java 
DeployedServices.ds, genere par Foutil d' administration dans le repertoire {%S0AP_H0ME3!}\webapps\ 
soap, vers le repertoire racine de 1' application Web de SW- Voyages, c'est-a-dire le repertoire 

{%T0MCAT_H0ME&}\webapps\reservation_sw- voyages. 
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Precisions sur le parametrage des deux tableaux de correspondances 

Le type d'encodage peut prendre les valeurs SOAP ou XMI : ici, le protocole SOAP est utilise. 

L'URI de I'espace de noms du type : il s'agit de I'espace de noms auquel appartient le type serialise (soit celui du 

partenaire, soit celui de SW-Voyages). 

Le nom de partie du schema : c'est le nom du type serialise (nom specifie dans le schema). 

Le nom qualifie de la classe Java : il s'agit du nom de classe qualifies Java correspondant au type du schema. 

Le nom qualifie de la classe Java de serialisation Java vers XML : ici, la classe de serialisation standard d'un bean, 

proposee par le moteur Apache SOAP, est utilisee. 

Le nom qualifie de la classe Java de deserialisation XML vers Java : ici, la classe de deserialisation standard d'un 

bean, proposee par le moteur Apache SOAP, est utilisee. 



Ceci a pour effet de placer ce descripteur de deploiement dans le classpath applicatif de 1' application de 
reservation de SW-Voyages et de permettre ainsi au moteur d' execution SOAP, deploye dans le repertoire 
des librairies {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\WEB-INF\lib, dele charger. 

Classes de support au service Web 

La classe d' implementation du service Web utilise quelques classes de servitude ou de support neces- 
saires a son fonctionnement. La plupart de ces classes implementent des interfaces Java qui ne sont 
pas reproduites ici. 

Classe ReservationManager.java 

L implementation du service Web utilise les services d'un registre local des reservations qui conserve 
les informations des sessions ouvertes depuis Fouverture du serveur d' applications (fichier Reserva- 
tionManager.java). Cette classe etend la classe Hashtable du SDK (telechargez le code source sur 
www.editions-eyrolles.com). 

Ce registre local des reservations a done pour objectif de maintenir une accessibilite immediate aux 
reservations en cours durant la plage d'ouverture de F application Web. Pour simplifier cette etude de 
cas, aucun systeme de gestion de la persistance des sessions et des reservations n'est mis en ceuvre. 

Classe Reservation.java 

Une reservation (fichier Reservation.java) conserve les informations relatives a la demande de 
l'utilisateur (caracteristiques du voyage) d'une part, et les disponibilites aeriennes, automobiles et 
hotelieres communiquees par les partenaires d' autre part (telechargez le code source sur 
www.editions-eyrolles.com). 

Classes AirAvailability.java, CarAvailability.java et HotelAvailability.java 

Les disponibilites gerees par SW-Voyages peuvent etre de trois types : aeriennes (classe AirAvaila- 
bility.java), automobiles (classe CarAvailability.java) et enfin hotelieres (classe HotelAvailabi- 
lity.java). Ces classes ont pour objectif de gerer les informations propres a une disponibilite en 
provenance d'un partenaire. 

Seul le fichier source de la classe Ai rAvai 1 abi 1 i ty . java (telechargez le code source sur www.editions- 
eyrolles.com) est reproduit ici : en effet, les deux autres classes manipulent des donnees de natures 
differentes, mais sont cependant construites sur le meme modele et leur presentation n'apporterait pas 
d'elements nouveaux, necessaires a une bonne comprehension du scenario. 
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Classe Reservation Exception. Java 

La derniere classe utilisee par l'ensemble des classes de servitude est une classe d'exception generi- 
que (ReservationException.java) mise en ceuvre dans toutes les situations d'anomalies rencontrees 
durant le fonctionnement du service Web (telechargez le code source sur www.editions-eyrolles.com). 

Applications Web des partenaires de SW-Voyages 

Face au serveur d'applications de l'agence de voyages, chacun des partenaires de SW-Voyages 
dispose de sa propre application Web existante (partie cliente et partie serveur). Pour simplifier, nous 
postulons que la partie cliente existante reste inchangee et n'entre pas dans le cadre de ce scenario. 

De fait, seule la partie serveur de 1' application sera consideree ici, car elle va permettre d'illustrer la 
continuite de service entre le navigateur de l'utilisateur final et les serveurs d'applications des centra- 
les de reservation, via le serveur de l'agence de voyages. Nous pouvons considerer que 1' implemen- 
tation serveur presentee ici est une evolution du systeme existant. 

De meme, 1' implementation de la centrale de reservation SW-Air constituera le seul exemple repro- 
duit dans cette etude de cas. En effet, les implementations des deux autres centrales de reservation 
SW-H6tels et SW-Voitures sont calquees sur le meme modele et leur presentation n'apporterait pas 
de precisions supplementaires. 

L'arborescence de 1' application Web de la societe SW-Air (contexte reservation_sw-ai r) se presente 
done telle que l'illustre la figure 23-4. 



El reservation_sw-. 



Jfljx] 



File Edit View Favorites Tools Help 



Address Q C:\Tonncat_4, 1.12-LE\webapps\reservation_sw-air 



II ^ 



Back Forward Up 



Search 



Folders History 



X ten 

Move To Copy To Delete Undo 



Views 



B-Q reservation_sw-air 
■■C~\ schemas 
- In services 
- il services-type 
E-Q WEB-INF 
B-il classes 
| BQ com 

B-Tn swair 

-in reservation 



L -Q lib 



J 



id 



Taille 



Il schemas 

\\ services 

\\ services-type 

Q WEB-INF 

|*| DeployedServices.ds 



iL 



l T VP e 



Dossier de Fichiers 
Dossier de Fichiers 
Dossier de fichiers 
Dossier de fichiers 
2 KB Fichier DS 



J 



5 objet(s) (Espace disque disponible : 943 MB) 



|l,27KB |g My Computer 



Figure 23-4 

Arborescence de V application Web de la societe SW-Air. 



L' application complete (partie cliente et partie serveur) est entierement localisee dans le repertoire 
{%TOMCAT_HOME&}\webapps\reservation_sw-air du serveur Tomcat. 
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Partie serveur de I 'application Web des partenaires de SW-Voyages 

La partie serveur de F application Web de SW-Air est entierement realisee sous forme de classes Java. 
Elle ne fait pas appel a la technologie des servlets car F utilisation du protocole HTTP est prise en 
charge directement par F implementation SOAP Apache. 

Interface Java du service Web 

II faut d'abord definir F interface Java qui va permettre d'exposer le nouveau service de reservation 
mis en place par la societe SW-Air (classe IReservationService.java, localisee dans le repertoire 
mOMCAT_HOME%}\webapps\reservation_sw-ai r\WEB-INF\cl asses \com\swai r\ reservation). Cette 
classe (telechargez le code source sur www.editions-eyrolles.com) comporte Fensemble des methodes 
qui seront exposees et accessibles a la partie serveur de la nouvelle application Web de SW-Voyages, via 
F implementation Apache SOAP : 

• La methode search permet au serveur de SW-Voyages de communiquer au serveur de SW-Air les 
caracteristiques du voyage souhaitees par Futilisateur final. Cette methode est activee dans Faction 
n°2 decrite dans la cinematique du processus (figure 23-3). 

• La methode book est utilisee pour confirmer au serveur de SW-Air le souhait de reservation de 
Futilisateur final. Cette methode est declenchee par Faction n°22 decrite dans la cinematique du 
processus (figure 23-3). 

• La methode cancel constitue le pendant de la methode book decrite ci-dessus. Elle est utilisee pour 
informer le serveur de SW-Air du souhait d'annulation de Futilisateur final. Cette methode est 
egalement declenchee par Faction n°22 decrite dans la cinematique du processus (figure 23-3). 

• La methode getAi rAvai 1 abi 1 1 ties permet au serveur SW-Voyages de recuperer les disponibilites 
de reservation aerienne et de les afflcher a destination de Futilisateur. Cette methode est activee par 
Faction n°l 1 decrite dans la cinematique du processus (figure 23-3). 

La classe d' interface Java definit ainsi quatre methodes d' interface qui seront accessibles a travers le 
service Web qui Fencapsulera. 

Generation de la description WSDL du service Web abstrait 

A partir de cette classe d' interface, il est maintenant possible de generer le fichier de definition du 
service Web (WSDL) de reservation. 

La description du service abstrait de la centrale de reservation SW-Air (fichier ReservationService- 
interface.wsdl, localise dans le repertoire { %TOMCAT_HOME£}\webapps\reservation_sw- a ir\ services - 
type) est effectuee dans le code source que vous pouvez telecharger sur www.editions-eyrolles.com. 

On reconnait dans ce fichier la description des messages echanges, le type de port unique qui decrit 
les quatre operations associees aux quatre methodes de F interface Java precedente et enfin la liaison 
au protocole SOAP, le seul admis pour ce service de reservation. 

Definition du schema associe au service Web abstrait 

Les structures de donnees necessaires au fonctionnement de ce service sont importees, via la refe- 
rence au schema de donnees correspondant (balise import). La description du schema de donnees 
(fichier ReservationService-interface.xsd, localise dans le repertoire {$TOMCAT_HOME%}\webapps\ 
reservation_sw-air\schemas) presente les elements suivants (telechargez le code source sur 
www.editions-eyrolles.com) : 
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definition d'un tableau de disponibilites aeriennes renvoye par la methode getAi rAvai 1 abi 1 i ti es 
(voir la liste des messages associes a cette methode dans la description du service abstrait : fichier 
ReservationService-interface.wsdl) ; 

definition d'un element du tableau de disponibilites aeriennes renvoye par la methode getAi rA- 
vai 1 abi 1 i ti es. 



Description WSDL de implementation du service Web 

II reste a decrire le point d'acces au service concret de reservation sur Internet, propose par SW-Air. 
La description du point d'acces au service (fichier Reservati onService.wsdl, localise dans le repertoire 
{%TOMCAT_HOME&}\webapps\reservation_sw-air\services) se presente ainsi : 

<?xml version="1.0" encoding="IS0-8859-l"?> 
<definitions 
name="ReservationService" 
t a rgetNamespace=" http://www.sw- air. com: 8080/ reservati on_sw- 

air/services/ReservationService" 
xmlns : tns=" http://www.sw- a ir.com : 8080/ reservati on_sw- 

air/services/ReservationService" 
xmlns :interface="http://www.sw-ai r. com: 8080/ reservati on_sw-air/services- 

type/ReservationService- interface" 
xmlns :soap=" http://schemas.xml soap.org/wsdl /soap/" 
xmlns=" http://schemas.xml soap.org/wsdl /"> 

<import namespace="http: //www. sw-air. com: 8080/ reservati on_sw-air/services- 
type/ Reservati onService- interface" 

1 oca tion="http: //www. sw-air. com :8080/reservation_sw-air/services- 
type/ReservationService-interface.wsdl"/> 

<service name="ReservationService"> 
<documentation>Acces au service de reservation de SW-Ai r.</documentation> 
<port binding=" interface: Reservati onService" name="ReservationService"> 
<soap:address 
1 oca tion="http : //www. sw-air. com: 8080/ reservati on_sw- 
air/servlet/rpcrouter"/> 
</port> 
</service> 
</definitions> 

On reconnait ici deux balises importantes : la balise import qui reference la description de service 
abstrait que nous avons generee precedemment et la balise servi ce qui fournit le point d'acces reel au 
service (attribut 1 ocati on de la balise address) accessible par le protocole SOAP. 

Generation du squelette et ('implementation du service Web 

La definition WSDL du service Web de reservation est desormais complete. A partir de cette defini- 
tion, nous pouvons maintenant generer un squelette d'implementation Java du service (skeleton) que 
nous pourrons ensuite completer selon nos besoins. Ce squelette implementera la classe d'interface 
Java definie au depart. 
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Cette classe (fichier ReservationService. Java, localise dans le repertoire {$TOMCAT_HOME%}\webapps\ 
reservation_sw-air\WEB-INF\classes\com\swair\reservation) implemente les methodes suivantes 
(telechargez le code source sur www.editions-eyrolles.com) : 

• search : l'invocation de cette methode est le resultat de Taction n°2 decrite dans la cinematique des 
echanges (figure 23-3) et declenchee par le serveur de SW- Voyages. Le numero de reservation 
attribue par le serveur de SW-Air est ensuite enregistre localement, puis restitue au serveur de SW- 
Voyages, ce qui correspond a Taction n°3. 

• book : l'invocation de cette methode est le resultat de Taction n°22 decrite dans la cinematique des 
echanges (figure 23-3) et declenchee par le serveur de SW- Voyages. Le serveur de SW-Air 
communique alors sa reponse au serveur de SW- Voyages, ce qui correspond a Taction n°23. 

• cancel : l'invocation de cette methode est le resultat de Taction n°22 decrite dans la cinematique 
des echanges (figure 23-3) et declenchee par le serveur de SW- Voyages. Le serveur de SW-Air 
communique alors sa reponse au serveur de SW- Voyages, ce qui correspond a Taction n°23. 

• getAi rAvai 1 abilities : l'invocation de cette methode est le resultat de Taction n°10 decrite dans la 
cinematique des echanges (figure 23-3) et declenchee par le serveur de SW- Voyages. Le serveur 
SW-Air renvoie ses disponibilites (action n°ll) au serveur de SW- Voyages. 

II faut noter ici que cette classe ne comporte que du code Java basique et n'utilise aucune librairie 
particuliere associee de pres ou de loin aux technologies de services Web. Ceci tient au fait que le 
moteur Apache SOAP est capable d'invoquer des methodes de classes Java standards ou d'EJB existants 
sans aucune adaptation. 

Deploiement du service Web 

Une fois la classe d'implementation du service Web ecrite, il est necessaire de la deployer a destination 
du moteur d' execution Apache SOAP incorpore dans T application Web de SW-Air. La procedure est 
identique a celle qui a deja ete mise en ceuvre lors du deploiement du service Web de SW- Voyages. 

Les informations a saisir dans l'ecran d' administration ecran sont : 

• Tidentifiant du service : ici urn: ReservationService ; 

• la portee du service : la portee est T application ; 

• les noms des methodes de la classe d'implementation exposees (separes par un caractere espace) : 
les methodes book, cancel, getAi rAvai labilities et search qui sont exposees dans notre exemple ; 

• le nom qualifie de la classe d'implementation Java : com. swair. reservation. ReservationService ; 

• le nombre de correspondances de types (Type mappings) utilisees par le service : une correspondance 
utilisee au total (voir ci-apres) ; 
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Correspondance de types serveur SW-Air/serveur SW-Voyages 



N° Caracteristiques Valeurs 


1 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http://www.sw-ai r. com: 8080/ reser vat ion_sw-air /sche- 
ma s/ Reservation Service- schema 


Norn de partie du schema 


AirAvai lability 


Norn qualifie de la classe Java associee a cette partie 


com.swair. reservation. Ai rAvailabil ity 


Nom qualifie de la classe Java de serialisation Java vers 
XML 


org. apache. soap. encoding. soapenc.BeanSerial izer 


Nom qualifie de la classe Java de deserialisation XML 
vers Java 


org. apache. soap. encoding. soapenc.BeanSerial izer 



Pour achever le deploiement, il ne nous reste plus qu'a copier le fichier de serialisation Java Depl oyedSer- 
vi ces . ds, genere par Foutil d' administration dans le repertoire USOAP J0ME%} \webapps\soap, vers le reper- 
toire racine de Fapplication Web de SW-Air, c'est-a-dire le repertoire {ZT0MCAT_H0MEX}\webapps\ 
reservatiorusw-ai r. Ceci a pour effet de placer ce descripteur de deploiement dans le classpath applicatif 
de Fapplication de reservation de SW-Air et de permettre ainsi au moteur d' execution SOAP, deploye dans 
le repertoire des librairies WTOMCAT_HOME%}\webapps\reservation_sw-ai r\WEB-INF\l ib, de le charger. 

Classes de support au service Web 

La classe ReservationManager. Java est strictement identique a celle de F implementation de SW- 
Voyages deja detaillee precedemment. II en est de meme pour la classe d' exception generique Reser- 
vation Exception, j a va. 

Classe Reservation. Java 

Une reservation (fichier Reservation.java) conserve les informations relatives a la demande de 
Futilisateur (caracteristiques du voyage) d'une part, et les disponibilites aeriennes communiquees a 
Fagence de voyages d'autre part. Son implementation (telechargez le code source sur www.editions- 
eyrolles.com) differe quelque peu de celle de SW-Voyages. 

Le writer utilise dans le constructeur de la classe est simplement utilise afin que le message imprime 
par la methode status (int, int) de la classe (confirmation d'annulation ou de reservation) appa- 
raisse correctement dans la fenetre de log du serveur, notamment en ce qui conceme les lettres accentuees 
(utilisation du codepage 850 dans le flux de sortie). 

La methode status (int, int) a pour seul objet d'afficher dans la log du serveur Tomcat le resultat de 
Factivation du bouton Annul er ou Reserver dans Finterface utilisateur de Fapplication Web de SW- 
Voyages (confirmation d'annulation ou de reservation). 

Dans un systeme plus proche de la realite, la methode getAi rAva i 1 abi 1 i ti es ( ) doit soit utiliser une 
base de donnees des disponibilites, soit faire appel a un sous-systeme capable de calculer les disponi- 
bilites en fonction des cri teres fournis par Futilisateur. Afin de simplifier le scenario, cette methode 
renvoie des disponibilites codees de maniere statique. Seule une requete, pour laquelle Faeroport de 
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depart est « Paris-CDG » et Faeroport d'arrivee est « Vienne », est susceptible de renvoyer un resul- 
tat, toujours le meme, quelles que soient les dates de depart et de retour ! Pour toute autre requete, les 
collections renvoyees sont vides. 

Classe AirAvailability.java 

Les seules disponibilites gerees par SW-Air sont aeriennes (classe AirAvailability.java). Cette 
classe (telechargez le code source sur www.editions-eyrolles.com) a pour objectif de gerer les infor- 
mations propres a une disponibilite communiquee a destination de SW- Voyage. 

Comme pour la classe de reservation, le writer utilise dans le constructeur de la classe est simplement 
utilise afin que le message imprime par la methode status ( ) de la classe (confirmation d'annulation 
ou de reservation) apparaisse correctement dans la fenetre de log du serveur. 

La methode status ( ) a pour seul objet d'afficher dans la log du serveur Tomcat le resultat de Factiva- 
tion du bouton Annul er ou Reserver dans Finterface utilisateur de l'application Web de SW- Voyages 
(confirmation d'annulation ou de reservation). La methode agit en delegation pour le compte de la 

classe Reservation. Java. 
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Implementation Java 



Ce chapitre est le premier d'une partie composee de deux chapitres dediee a la presentation d'une 
architecture de service dynamique. Cette implementation s'appuie sur l'exploitation d'un annuaire 
UDDI pour decouvrir a l'execution les points d'acces des services de reservation des partenaires de 

SW- Voyages. 

Cette deuxieme generation du logiciel de reservation correspond au scenario numero 2 presente dans 
le chapitre 22. 

L' implementation du service Web de SW- Voyages fait toujours appel a la technologie Java. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenai- 
res est maintenu sous forme d'installation d' applications Web. Le deploiement des nouveaux partenaires 
(organisations sectorielles) doit egalement etre realise sous cette forme. 

Produits utilises 

Les produits utilises dans ce deuxieme scenario sont identiques a ceux qui ont ete mis en ceuvre dans 
le premier scenario. 

A cette liste de produits, il convient cependant d'ajouter 1' annuaire UDDI utilise pour la publication 
et la recherche des descriptions de services de reservation abstraits, ainsi que les caracteristiques des 
services concrets qui implementent ces descriptions de services abstraits. 
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Ann de nous liberer des contraintes fortes imposees par les operateurs du conseil de l'UBR quant au 
nombre des entrees d'annuaire qui peuvent etre creees par un compte de publication de premier 
niveau, nous n'allons pas utiliser les annuaires publics tenus par ces operateurs. 

De nombreuses implementations d'annuaires UDDI prives sont aujourd'hui disponibles (voir le 
chapitre 12 « Publier un service »). 

The Mind Electric GLUE Professional 3. 1 

Nous allons utiliser ici celle du produit Glue Professional de la societe The Mind Electric qui a le 
merite d'etre tres simple a utiliser en developpement. En effet, la persistance des donnees n'est pas 
realisee dans une base de donnees relationnelle, mais plus simplement sous la forme de fichiers XML 
stockes dans le systeme de fichiers du systeme d' exploitation. 

Les fonctionnalites UDDI (client et serveur) de Glue Professional ne constituent qu'une partie du 
produit car Glue Professional est une plate-forme complete de developpement, de deploiement et 
d' execution de services Web. Nous n'utiliserons done qu'une petite partie seulement du produit. 

Le produit The Mind Electric Glue Professional peut etre telecharge a partir de l'adresse http:// 
www.themindelectric.net/download. La version 3.1 du serveur, utilisee dans cet exemple, n'est plus dispo- 
nible, car ce produit evolue tres frequemment pour integrer de nouvelles fonctionnalites. Cependant, 
la plupart du temps, le code developpe pour une version donnee reste valable tel quel pour une 
version plus recente. 

Le repertoire d' installation C:\electric du moteur d'execution de services Web Glue Professional 
sera represente par la variable {%GLUE_HOMEZ}. 



Parametrage des produits 



A l'instar du parametrage des produits, realise dans le cadre du premier scenario, il est necessaire de 
realiser quelques modifications supplementaires pour permettre le fonctionnement de cette seconde 
maquette. 

II faut notamment autoriser les requetes HTTP adressees aux quatre nouveaux domaines (www.sw- 
tourisme-xml .org, www.sw-aviation-xml .org, www.sw-hotel lerie-xml .org et www.sw-automobil isme- 
xml.org), ainsi qu'au domaine de l'annuaire UDDI (www.sw-registre-uddi.org), a aboutir sur 
l'unique serveur d'applications Web Tomcat (domaines des quatre organisations sectorielles) et sur le 
serveur Glue (domaine de l'annuaire UDDI), tous deux installes sur la meme machine. Pour cela, il 
est necessaire d'effectuer deux reglages prealables, complementaires a ceux qui ont deja ete realises 
precedemment lors du deroulement du premier scenario : 

1. Modifier le fichier Host du systeme d'exploitation en y ajoutant les lignes suivantes (fichier 
C:\winnt\system32\drivers\etc\hosts sous Windows 2000, par exemple) : 

127.0.0.1 www.sw-tourisme-xml .org 

127.0.0.1 www.sw-aviation-xml .org 

127.0.0.1 www.sw-hotellerie-xml .org 

127.0.0.1 www.sw-automobil isme-xml .org 

127.0.0.1 www.sw-registre-uddi .org 
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2. Modifier le fichier de configuration de Tomcat en y ajoutant autant d'hotes virtuels que de 
nouveaux domaines pris en charge, sauf celui de l'annuaire UDDI qui n'est pas integre dans le 
serveur d' applications Tomcat (fichier {%TOMCAT_HOME?}\conf\server.xml sous Windows 2000, 
par exemple) : 

Definition de l'hote virtuel www.sw-tourisme-xml .org : 

<Host name="www.sw-tourisme-xml .org" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-tourisme-xml " 
docBase="reservation_sw- tour i sine -xml " 
debug="0" reloadable="false" crossContext="false"> 
< Logger cl as sName= "org. apache. catalina.logger.FileLogger" 
prefix="reservation_sw-tourisme-xml_log. " suffix=" .txt" 
timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote virtuel www. sw-av iation-xml.org : 

<Host name="www.sw-aviation-xml .org" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-aviation-xml " 
docBase="reservation_sw-aviation-xml " 
debug="0" reloadable="false" crossContext="false"> 
< Logger className="org. apache. catalina.logger.FileLogger" 
prefix="reservation_sw-aviation-xml_log. " suffix=" .txt" 
timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote virtuel www.sw-hotellerie-xml .org : 

<Host name="www.sw-hotellerie-xml .org" appBase="webapps" unpackWARs="true"> 
<Context pa th="/reservation_sw- hotel lerie-xml " 
docBase="reservation_sw- hotel lerie-xml " 
debug="0" reloadable="false" crossContext="false"> 
< Logger className="org. apache. catalina.logger.FileLogger" 
prefix="reservation_sw-aviation-xml_log. " suffix=" .txt" 
timestamp="true"/> 
</Context> 
</Host> 

Definition de l'hote virtuel www. sw-automobilisme-xml .org : 

<Host name="www.sw-automobil isme-xml .org" appBase="webapps" unpackWARs="true"> 
<Context path="/reservation_sw-automobilisme-xml " 
docBase="reservation_sw-automobil isme-xml " 
debug="0" reloadable="false" crossContext="false"> 
< Logger className="org. apache. catalina.logger.FileLogger" 
prefix="reservation_sw-aviation-xml_log. " suffix=" .txt" 
timestamp="true"/> 
</Context> 
</Host> 
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Les applications Web supplementaires qui correspondent aux quatre domaines associes aux nouvel- 
les organisations (www.sw-tourisme-xml.org, www.sw-aviation-xml.org, www.sw-hotellerie-xml.org 
et www.sw-automobilisme-xml .org) sont done deployees dans le serveur d' applications Tomcat qui 
presente alors l'arborescence montree figure 24-1 : 
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Figure 24-1 

Arborescence des applications Web deployees dans le serveur Tomcat. 

Les applications Web deployees pour chacune des quatre organisations sont reduites a la plus simple 
expression. Elles comportent uniquement trois repertoires : 

• le repertoire schemas, qui comporte Funique schema des types de donnees utilises par la description 
de service abstrait ; 

• le repertoire services-type qui comprend la description de service abstrait au format WSDL ; 

• le repertoire WEB-INF, qui heberge seulement le fichier web . xml impose par la specification Servlets. 

Ces quatre applications ne renferment done aucun code executable (pas de sous -repertoires cl asses 
et 1 i b). Elles ne sont constituees que par du code descriptif. De maniere symetrique, on peut noter 
que les repertoires schemas et services-type, deployes dans les quatre applications Web de chacune 
des societes commerciales lors du premier scenario, sont purement et simplement supprimes ici, au 
profit des quatre nouvelles applications. 
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Ce transfert est du ail fait que les services de reservation sont maintenant standardises et que les refe- 
rentiels correspondants passent sous le controle des organismes sectoriels. 

Afin de rendre ce transfert effectif, il est necessaire de redeployer les schemas et descriptions de 
services abstraits de la maniere suivante : 

1. Redeploiement du referentiel de SW-Air vers SW- Aviation-XML : 

- deplacer le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-air\scriemas\ReservationSer- 
vice-interface.xsd dans le repertoire {%T0MCAT_H0ME%}\webapps\reservat1on_sw-av1at1on- 

xml \schemas ; 

- deplacer le fichier {nOMCAT_HOME%}\webapps\reservation_sw-air\services-type\Reserva- 
tionService-interface.wsdl dans le repertoire UTOMCAT_HOME%}\webapps\reservation_sw- 
aviation-xml \services-type ; 

- supprimer le repertoire {%TOMCAT_HOME£}\webapps\reservation_sw-air\schemas ; 

- supprimer le repertoire {%TOMCAT_HOMEX}\webapps\reservation_sw-ai r\services-type. 

2. Redeploiement du referentiel de SW-H6tels vers SW-Hotellerie-XML : 

- deplacer le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-hotels\schemas\Reservation- 
Service-interface.xsd dans le repertoire {%TOMCAT_HOME£}\webapps\reservation_sw-hotel- 
lerie-xml \schemas ; 

- deplacer le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-hotels\services-type\Reser- 
vationService-interface.wsdl dans le repertoire UTOMCAT_HOME%}\webapps\reservation_sw- 
hotel 1 erie-xml \services-type ; 

- supprimer le repertoire {%TOMCAT_HOME£}\webapps\reservation_sw-hotels\schemas ; 

- supprimer le repertoire {%TOMCATJOMEX}\webapps\reservation_sw-hotels\services-type. 

3. Redeploiement du referentiel de SW-Voitures vers SW-Automobilisme-XML : 

- deplacer le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-voitures\schemas\Reserva- 
tionService-interface.xsd dans le repertoire {XTOMCAT„HOME%}\webapps\reservation_sw- 
automobil isme-xml \schemas ; 

- deplacer le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-voitures\services-type\ 
ReservationService-interface.wsdl dans le repertoire {%TOMCAT_HOME%}\webapps\ 
reservation_sw-automobi 1 isme-xml \services-type ; 

- supprimer le repertoire {%TOMCAT_HOME&}\webapps\reservation_sw-voitures\schemas ; 

- supprimer le repertoire {%TOMCATJOMEX}\webapps\reservation„sw-voitures\services-type. 

4. Redeploiement du referentiel de SW- Voyages vers SW-Tourisme-XML : 

- deplacer le fichier {%T0MCAT_H0ME£} \webapps\reservati on_sw-voyages\schemas\Reservati on- 
Service-interface.xsd dans le repertoire {%TOMCAT_HOME%}\webapps\reservation_sw- 
tourisme-xml \schemas ; 
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- deplacer le fichier {%T0MCAT_H0ME3!}\webapps\reservation_sw-voyages\services-type\Reser- 
vationService-interface.wsdl dans le repertoire {%T0MCAT_H0ME£}\webapps\reservation_sw- 
tourisme-xml \services-type ; 

- supprimer le repertoire {%T0MCATJH0ME%}\webapps\reservation_sw-voyages\schemas ; 

- supprimer le repertoire UTOMCAT_HOME%}\webapps\reservation_sw-voyages\services-type. 

Pour finaliser ce transfert entre domaines, il faut encore adapter les espaces de noms des descrip- 
tions de services et des schemas. Pour cela, a l'aide d'un editeur de texte, il faut modifier les 
fichiers correspondants de la facon suivante : 

• Fichier {$TOMCAT_HOME$}\webapps\reservation_sw-ai r\ schema s\Reser vat ionServ ice- i inter- 
face, xsd : 

- remplacer targetNamespace="http://www.sw-ai r .com:8080/reservation_sw-ai r/ schemas/ 
ReservationService-schema" par targetNamespace="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-aviation-xml /schemas/ReservationService-schema" ; 

- remplacer xml ns :tns="http: //www.sw-ai r.com:8080/reservation_sw-ai r/ schemas /Reserva- 
tionService-schema" par xmlns :tns="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-aviation-xml /schemas/ ReservationService-schema". 

• Fichier {%TOMCAT_HOME%}\webapps\reservation_sw-ai r\services- type \ Reservation Serv ice- 
interface. wsdl : 

- remplacer t a rget Names pa ce=" http://www.sw- a i r.com:8080/reservation_sw-ai r /services - 
type/ ReservationService- interface" par targetNamespace="http: //www.sw-aviation- 
xml .org: 8080/ reservation_sw-aviation-xml /services -type/ ReservationService- inter- 
face" ; 

- remplacer xml ns:tns="http: //www.sw-ai r .com:8080/reservation_sw-ai r /services -type/ 
ReservationService-interf ace" par xmlns :tns="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-aviation-xml /services -type/ ReservationService- interface" ; 

- remplacer xml ns :xsdl="http: //www.sw-ai r.com:8080/reservation_sw-ai r/schemas/ Reserva- 
tionService-schema" par xmlns :xsdl="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-aviation-xml /schemas/ ReservationService- schema" ; 

- remplacer names pa ce="http: //www.sw-ai r.com:8080/reservation_sw-ai r/schemas /Reserva- 
tionService-schema" par namespace="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-aviation-xml /schemas/ReservationService-schema" ; 

- remplacer 1 ocation="http: //www.sw-ai r .com:8080/reservation_sw-ai r/schemas /Reserva- 
tionService-interface.xsd" par location="http://www.sw-aviation-xml .org:8080/ 
reservation_sw-avi ation-xml /schemas/ ReservationService- interface. xsd". 
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Des modifications equivalentes doivent etre realisees dans les six autres fichiers redeployes selon 
le tableau des correspondances de noms suivant : 

Correspondances des noms 



Entites 


Valeurs initiales 


Valeurs finales 




Hotes 


http://www.sw-air.com:8080 


http://www.sw-aviation-xml.org.8080 




http://www.sw-hotels.com-.8080 


http://www.sw-hotelierie-xml.org:8080 




http://www.sw-voitures.com:8080 


http://www.sw-automobilisme-xml.org:8080 




http://www.sw-voyages.com:8080 


http://www.sw-tourisme-xml.org:8080 




Contextes applicatifs 


reservation_sw-ai r 


reservation_sw-aviation-xml 




reservation_sw- hotels 


reservati on_sw- hotel 1 eri e-xml 




reservation_sw-voitures 


reservati on_s w- a utomobil isme-xml 




reservation_sw- voyages 


reservati on_sw- tour isme-xml 


1 



Ces modifications effectuees, il reste a modifier les descriptions WSDL des services concrets afin de 
refleter ces changements. Pour cela, il faut adapter les quatre fichiers concernes : 

• Fichier {%TOMCAT_HOME%}\webapps\reservation_sw-air\services\ReservationService.wsdl : 

- remplacer xmlns: interface="http://www.sw-ai r.com:8080/reservation_sw-air/services- 
type/ReservationService- interface" par xml ns:interface=" http://www.sw-a viation- 
xml .org: 8080/ reservati on_sw-aviation-xml /servi ces -type/ReservationService- interface" ; 

- remplacer names pace=" http://www.sw- a i r .com: 8080/ reservati on_sw- a i r /servi ces -type/ 
ReservationService-interface" par namespace="http://www.sw-aviation-xml .org:8080/ 
rese rvat i on_sw- avi at i on -xml /servi ces -type/ReservationService- interface" ; 

- remplacer location="http://www.sw-ai r. com: 8080/ reservati on_sw-ai r /servi ces -type/ Reser- 
vati onService- interface, wsdl " par location="http://www.sw-aviation-xml .org: 8080/ 
reservation_sw-aviation-xml /servi ces -type/ Reservati onService- interface. wsdl ". 

• Fichier {%TOMCAT_HOME%}\webapps\reservation_sw-hotels\services\ReservationService.wsdl : 

- remplacer xml ns: interface^" http://www.sw- hotel s. com : 8080/ rese rvation_sw- hotels /servi - 
ces -type/ Reservati onService- interface" par xml ns:interface=" http://www.sw- hotel lerie- 
xml . o rg : 8080/ res erva tion_sw- hotel 1 eri e-xml /servi ces -type/ Reservati onService -inter- 
face" ; 

- remplacer namespace=" http://www.sw- hotel s. com: 8080 /rese rvat ion_sw- hotels /services- 
type/ Reservati onService- interface" par names pa ce=" http://www.sw- hot el 1 erie- 
xml . o rg : 8080/ res erva tion_sw- hotel 1 eri e-xml /servi ces -type/ Reservati onService -inter- 
face" ; 

- remplacer location^" http://www.sw- hotel s. com: 8080/ reservati on_sw- hotel s /servi ces -type/ 
Reservati onService- interface. wsdl " par 1 oca tion=" http://www.sw- hotel lerie- 
xml .org:8080/reservation_sw-hotel 1 eri e-xml /servi ces -type/ Reservati onService -inter- 
face. wsdl ". 
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• Fichier {%TOMCAT_HOME%}\webapps\reservation_sw-voi tures \servi ces \ Reservati onService. wsdl : 

- remplacer xml ns : i nterf ace=" http : //www . sw-voi tures . com: 8080/ reservati on_sw-voi tures/ 
servi ces - type/ ReservationService-i interface" par xml ns:i nterf ace=" http: //www. sw-automobi- 
1 isme-xml . org: 8080/ reservati on_sw-automobil isme-xml /servi ces -type/ Reservati onService- 
interface" ; 

- remplacer namespace=" http: //www. sw-voi tures. com: 8080/ reservati on_sw-voi tures/servi ces- 
type/ReservationService- interface" par namespace="http://www.sw-automobil isme- 
xml .org: 8080/ reservati on_sw-automobil isme-xml /servi ces -type/ Reservati onServ ice- inter- 
face" ; 

- remplacer location=" http: //www. sw-voi tures. com: 8080/ reservati on_sw-voi tures /services- 
type/ Reservati onService- interface, wsdl " par location^ "http:/ /www. sw-automobil isme- 
xml .org: 8080/ reservati on_sw-automobil isme-xml /servi ces -type/Reservati onService- inter- 
face. wsdl ". 

• Fichier mOMCAT_HOME%}\webapps\reservation_sw-voyages\services\ReservationService.wsdl : 

- remplacer xml ns : i nterf ace=" http://www.sw- voyages .com: 8080/ reservati on„sw- voyages /servi- 
ces -type/ Reservati onService- interface" par xml ns:i nterf ace=" http: //www. sw-tourisme- 
xml .org: 8080/ reservati on_sw-tourisme-xml /servi ces -type/ Reservati onService- interface" ; 

- remplacer namespa ce=" http: //www. sw- voyages, com: 8080/ reservati on_sw-voy ages/services - 
type/ReservationService-interface" par namespace="http://www.sw-tourisme-xml .org:8080/ 
reservati on_sw-tour isme-xml /servi ces -type/ Reservati onService- interface" ; 

- remplacer 1 ocation=" http: //www. sw- voyages. com: 8080/ reservati on_sw- voyages/services -type/ 
Reservati onService- interface. wsdl " par 1 oca t ion=" http:/ /www. sw-tour isme-xml .org: 8080/ 
reservati on_sw- tour isme-xml /servi ces -type/ Reservati onService- interface. wsdl ". 

Enfin, sous le repertoire WEB- INF des quatre nouveaux domaines, un fichier web. xml dont le contenu 
est le suivant doit etre ajoute : 

<?xml version="1.0" encoding="IS0-8859-l"?> 
<!D0CTYPE web-app 

PUBLIC "-//Sun Microsystems, Inc. //DTD Web Application 2.3//EN" 
"http://java.sun.com/dtd/web-app_2_3.dtd"> 
<web-app> 
<mime-mapping> 
<extension>xml</extension> 
<mime-type>text/xml</mime-type> 
</mime-mapping> 
<mime-mapping> 
<extension>xsd</extension> 
<mime-type>text/xml</mime-type> 
</mime-mapping> 
<mime-mapping> 
<extension>wsdl </extension> 
<mime-type>text/xml</mime-type> 
</mime-mapping> 
</web-app> 
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Ce fichier doit etre cree sous les repertoires : 

• {%TOMCAT_HOME%}\webapps\reservation_sw-autorriobilisrne-xrnl\WEB-INF ; 

• {UOMCAT_HOME%}\webapps\reservation_sw-aviation-xrnl\WEB-INF ; 

• {UOMCATJOME%}\webapps\reservation_sw-hotellerie-xnil\WEB-INF ; 

• {UOMCAT_HOME$}\webapps\reservation_sw-tourisrne-xrnl\WEB-INF. 

A Tissue de ces redeploiements et des modifications de fichiers associees, les quatre nouveaux 
serveurs des organisations sectorielles sont deployes et prets a demarrer. De meme, les descriptions 
WSDL des points d'acces aux implementations des quatre societes commerciales referencent main- 
tenant les descriptions WSDL des services abstraits et les schemas associes dont les references sont 
detenues par les nouvelles organisations sectorielles. Ces nouvelles references annulent et rempla- 
cent les references proprietaries des quatre societes commerciales utilisees dans le premier scenario. 

Un dernier changement, lie aux modifications des espaces de noms, doit etre realise dans les descrip- 
teurs de deploiement des services Web des quatre partenaires commerciaux. En effet, ces descripteurs 
integrent une reference a l'espace de noms des types serialises et deserialises pour les besoins de 
fonctionnement de ces services Web. La procedure de modification est la suivante : 

1. Utiliser l'outil d'administration fourni avec le moteur SOAP, accessible a l'URL http://local- 
host:8080/soap/admin/index.html, selon la procedure deja decrite dans le premier scenario (voir figure 23-3). 

2. Saisir dans cet ecran les informations suivantes pour le descripteur de deploiement de F applica- 
tion Web de SW- Voyages : 

- l'identifiant du service : urn:ReservationService ; 

- la portee du service : la portee est de niveau appl i cati on ; 

- les noms des methodes de la classe d'implementation exposees (separes par un caractere espace) : 
book, cancel, search, getAi rAvai labilities, getCarAvai labilities et getHotelAvailabil ities ; 

- le nom qualifie de la classe d'implementation Java : com. swvoyages . reservati on . ReservationServi ce ; 

- le nombre de correspondances de types : six correspondances utilisees au total (voir les tableaux ci- 
apres). 

Trois correspondances de types Navigateur/serveur SW-Voyages (inchange) 



N° Caracteristiques Valeurs 


1 


Type d'encodage 


SOAP 


URI de l'espace de noms du type 


http: // www. sw- voy a ges.com: 8080 /reservation_sw- voyages/ 
schemas /Reservati onService-schema 


Nom de partie du schema 


Ai rAvai 1 abi 1 ity 


Nom qualifie de la classe Java associee a 
cette partie 


com. swvoyages. reservati on. AirAvailabil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deserialisa- 
tion XML vers Java 


org. apache, soap. encoding. soapenc.BeanSerializer 
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Trois correspondances de types Navigateur/serveur SW-Voyages (inchange) (suite) 



N Caracteristiques Valeurs 


2 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: //www. sw- voyages, com : 8080/ res ervation_sw- voyages/ 
s chema s/ Res ervationSer vice -schema 


Norn de partie du schema 


CarAvailabil ity 


Nom qualifie de la classe Java associee a 
cette partie 


com. swvoy ages. reser vat ion. CarAvailabil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. en coding. soapenc.BeanSerial izer 


Nom qualifie de la classe Java de deserialisa- 
tion XML vers Java 


org. apache. soap. en coding. soapenc.BeanSerializer 


3 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: //www. sw- voyages, com : 8080/ res ervation_sw- voyages/ 
s chema s/ Res ervationSer vice -schema 


Nom de partie du schema 


Hotel Avail abil ity 


Nom qualifie de la classe Java associee a 
cette partie 


com. swvoy ages. reser vat ion. Hotel Avail abil ity 


Nom qualifie de la classe Java de serialisation 
Java vers XML 


org. apache. soap. en coding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deserialisa- 
tion XML vers Java 


org. apache. soap. en coding. soapenc.BeanSerializer 



Trois correspondances de types serveur SW-Voyages/serveurs partenaires (modifie) 



N° Caracteristiques Valeurs 


1 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http: //www. sw-aviation-xml . org: 8080/ reservation_sw-a via - 
tion-xml /s chema s / Res ervationServ ice -schema 


Nom de partie du schema 


Ai rAvailabil ity 


Nom qualifie de la classe Java associee a 
cette partie 


com.swvoyages. reser vat ion. Air Avail abil ity 


Nom qualifie de la classe Java de serialisa- 
tion Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerial izer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. encoding. soapenc.BeanSerial izer 



Architecture dynamique (UDDI) - Implementation Java 

Chapitre 24 



Trois correspondances de types serveur SW-Voyages/serveurs partenaires (modifie) (suite) 



N" Caracteristiques Valeurs 


2 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http://www.sw-automobil isme-xml . org: 8080/ reservation_sw- 
automobil isme-xml /schemas/ReservationService-schema 


Nom de partie du schema 


CarAvailabi 1 ity 


Nom qualifie de la classe Java associee a 
cette partie 


com. swvoy ages. reser vat ion. Car Avail abil i ty 


Nom qualifie de la classe Java de serialisa- 
tion Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerial izer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. encoding. soapenc. Bean Serializer 


3 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http://www.sw-hotellerie-xml . org: 8080/ reservation_sw- 
hotel 1 er i e -xml / schema s/ Reservation Service -schema 


Nom de partie du schema 


Hotel Avail abil ity 


Nom qualifie de la classe Java associee a 
cette partie 


com. swvoy ages. reser vat ion. Hotel Avail abil ity 


Nom qualifie de la classe Java de serialisa- 
tion Java vers XML 


org. apache. soap. encoding. soapenc.BeanSerial izer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. encoding. soapenc.BeanSerial izer 



3. Apres le deploiement, copier le fichier de deploiement Java DeployedServices.ds, genere par 
l'outil d'administration dans le repertoire {%S0AP_H0ME3!}\webapps\soap, vers le repertoire racine 
de l'application Web de SW-Voyages, c'est-a-dire le repertoire {%T0MCAT_H0ME%}\webapps\ 
reservation_sw- voyages. 

La procedure de modification pour l'application Web de SW-Air est presentee ci-apres. Elle n'est pas 
reproduite ici pour les applications de SW-H6tels et SW-Voitures car elle est strictement identique a 
celle de SW-Air, aux transpositions de noms pres (methodes, classes d' implementation et espaces de 
noms). La procedure qui s' applique est done la suivante : 

1. Utiliser l'outil d'administration fourni avec le moteur SOAP, comme pour SW-Voyages. 

2. Saisir dans cet ecran les informations suivantes pour le descripteur de deploiement de l'applica- 
tion Web de SW-Air: 

- l'identifiant du service : urn:ReservationService ; 

- la portee du service : la portee est de niveau appl icati on ; 

- les noms des methodes de la classe d'implementation exposees (separes par un caractere 
espace) : book, cancel, search et getAi rAvailabil ities ; 

- le nom qualifie de la classe d'implementation Java : com. swair. reservation. ReservationSer- 

vice ; 



Etudes de cas 
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- le nombre de correspondances de types : une correspondance utilisee ail total (voir le tableau 
ci-apres) ; 

Correspondance de types serveur SW-Air/serveur SW-Voyages 



N° Caracteristiques Valeurs 


1 


Type d'encodage 


SOAP 


URI de I'espace de noms du type 


http://www.sw-aviation-xml . org: 8080/ reservati on_sw-avi a- 
tion-xml /schemas/ReservationService-schema 


Norn de partie du schema 


Ai rAvailabil ity 


Nom qualifie de la classe Java associee a 
cette partie 


com.swair. r ese r va t i on. Ai rAvailabil ity 


Nom qualifie de la classe Java de serialisa- 
tion Java vers XML 


org. apache. soap, en coding. soapenc.BeanSerializer 


Nom qualifie de la classe Java de deseriali- 
sation XML vers Java 


org. apache. soap. en coding. soapenc.BeanSerializer 



3. Apres le deploiement, copier le fichier de deploiement Java Depl oyedServi ces . ds, genere par l'outil 
d'administration dans le repertoire {%S0AP„H0ME%}\webapps\soap, vers le repertoire racine de Impli- 
cation Web de SW-Air, c'est-a-dire le repertoire {ITOMCAT_HOME%}\webapps\reservation_sw-ai r. 

Developpement 

La cinematique des echanges entre les serveurs, decrite dans le chapitre 22 (voir la section « Scenario 
n°2 »), ne peut etre declenchee qu' apres la realisation d'un prealable important. 

En effet, il est tout d'abord necessaire que toutes les entites metier qui interviennent dans le processus 
de reservation se soient enregistrees dans I'annuaire UDDI, public ou prive (extranet), utilise par les 
partenaires engages dans le processus : les quatre societes commerciales (ou centrales de reservation), 
ainsi que les quatre organisations sectorielles. 

Ensuite, les quatre organisations sectorielles doivent publier les caracteristiques des modeles abstraits 
de reservation (services types) qu'elles controlent a destination de I'annuaire UDDI afin que ceux-ci 
puissent etre references par les services qui les implementent. 

Enfin, les quatre centrales de reservation doivent egalement publier les caracteristiques des services 
commerciaux de reservation qu'elles implementent, sur la base des modeles abstraits de reservation 
prealablement publies par les organisations sectorielles auxquelles elles sont rattachees. 

Publication des modeles et services a destination de I'annuaire UDDI 

La publication des modeles et implementations de services de reservation a destination d'un annuaire 
UDDI peut etre realisee par deux moyens : 

• soit par l'utilisation de l'interface applicative Web, generalement fournie avec F implementation du 
serveur UDDI ; 
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• soit par Fecriture de scripts qui s'appuient sur l'utilisation de l'API cliente de publication UDDI. 

Dans ce deuxieme scenario, nous allons nous placer dans la seconde hypothese, ce qui va nous 
permettre de mettre en ceuvre F implementation UDDI cliente de Glue Professional. 

Pour cela, il est necessaire de creer autant de sous-repertoires de scripts que de domaines dans le 
repertoire d' installation de Glue (%GLUE_H0ME%}, A la suite de cette operation, l'arborescence du 
serveur Glue doit etre similaire a celle representee figure 24-2 : 
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Figure 24-2 

Arborescence du serveur Glue Professional. 

Scripts de gestion du nceud serveur UDDI 

Ces scripts sont stockes dans le repertoire {XGLUE_HOME%}\scripts_SW-Registre-UDDI.org et sont 
necessaires a la gestion de Fannuaire UDDI lui-meme. 

Le script Server. Java permet de demarrer le nceud UDDI : 

import el ectric. serve r.http. HTTP; 

import el ectric. uddi .server.xml .UDDI Server; 

public class Server { 

public static void mainCString[] args) throws Exception { 

boolean delete = (args. length == | | args[ ] .equalsC'true") ) ; 
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II Demarrage du serveur HTTP de traitement des requites de recherche. 
HTTP.startup( "http://www.sw-registre-uddi .org:8004/glue/inquire" , 
"/inquire") ; 

// Demarrage du serveur HTTP de traitement des requetes de publication 
(HTTPS optionnel). 

HTTP. st art up ( "http://www.sw-registre-uddi .org:8006/glue/publish" , 
"/publ ish") ; 

// Demarrage du serveur UDDI (si delete==true, destruction prealable du 
contenu de 1 'annuai re) . 

UDDIServer server = new UDDIServer("inquire/uddi" , "publ ish/uddi " , 
"publish/admin", "./uddi", delete); 



} 
} 

Ce script demarre done deux serveurs HTTP prets a servir des requetes de consultation UDDI 
(port 8004) ou des requetes de publication UDDI (port 8006), ici en mode non securise, mais le 
protocole HTTPS peut etre eventuellement utilise. 

Enfin, le serveur UDDI est demarre et publie les interfaces des services qu'il expose : inquire/uddi 
(API de consultation UDDI), publ ish/uddi (API de publication UDDI) et publish/admin (API 
d' administration du serveur). 

Ce serveur est administre par un utilisateur qui doit etre declare via FAPI d' administration du 
serveur. C'est le role du script Administrator. Java, fourni ci-apres : 

import electric. uddi .admin. IAdmin; 
import electric. uddi .admin. User; 
import el ectric. registry .Registry ; 

public class Administrator { 

public static void main(String[] args) throws Exception { 

// Acquisition du lien avec 1 'interface d'administration du serveur UDDI. 
IAdmin admin = (IAdmin) Registry .bind ( 
"http://www.sw-registre-uddi .org:8006/glue/publish/admin.wsdl" , 

IAdmin. cl ass) ; 

// Ajout d'un utilisateur. 
User user = new User( ) ; 
user.setNamet "uddi " ) ; 
user. set Pas sword ( "uddi") ; 
user. set Publ ish (true) ; 
user.setMaxBusinesses(lO) ; 
user.setMaxTModels(lO) ; 
user.setMaxServices(lO) ; 
user.setMaxBindings(20) ; 
admin. saveUser(user) ; 
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II Enregistrement de 1 'utilisateur. 

System. out. pri ntl n( "util isateur enregistre\n" + user); 



Les deux scripts doivent etre executes dans l'ordre qui suit : 

1. Server. Java ; 

2. Administrator. Java. 

Publication du modele de reservation aerienne 

Ces scripts sont stockes dans le repertoire {KLUE_HOME%}\scripts_SW-Aviation-xml .org et permet- 
tent de publier Fentite metier SW-Avi ati on-XML d'une pail, et le modele abstrait du service de reservation 
aerienne sw-aviation-xml -org: reservation d' autre part. 

Le script BusinessEntity . Java publie tout d'abord les coordonnees de Fentite SW-Aviation-XML : 

mport electric. uddi .Address; 

mport electric. uddi .Business; 

mport electric. uddi .Category ; 

mport electric. uddi .Contact; 

mport electric. uddi .Description; 

mport el ectric. uddi .Email ; 

mport electric. uddi . IUDDI ; 

mport el ectric. uddi . I UDDI Constants; 

mport electric. uddi .Phone; 

mport el ectric. uddi .UDDI Exception; 

mport el ectric. uddi .cl ient.UDDICl ient; 

public class BusinessEntity { 

public static void main(String[] args) throws Exception { 

String businessEntityName = "SW-Aviation-XML"; 

Le code ci-apres permet de recuperer les parametres de connexion a l'annuaire UDDI choisi, a savoir 
l'URL de consultation, FURL de publication et les coordonnees de Futilisateur. Cette partie de code, 
identique dans tous les exemples de scripts qui suivent, sera omise dans les prochains scripts. 

String inquireURL = ""; 

String publishURL = ""; 

String user = ""; 

String password = ""; 

// Recuperation des parametres de l'annuaire UDDI. 
iftargs. length > 0) { 

inquireURL = args[0] ; 

publishURL = args[l]; 

user = args[2]; 

password = args[3]; 
) 
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if ( i nqui reURL. equal s( " " ) ) { 

inqui reURL = "http://www.sw-registre-uddi .org:8004/glue/inquire/uddi" 
} 
if (publishURL.equalsC"')) { 

publ ishURL = "http://www.sw-registre-uddi .org:8006/glue/publish/uddi" 
} 
if ( user. equal sC" ) ) { 

user = "uddi " ; 
} 
if (password. equal sC" ) ) { 

password = "uddi " ; 



// Instanciation du client UDDI. 

IUDDI uddi = new UDDIC1 ientO'nquireURL, publishURL, user, password); 

// Instanciation de l'entite metier. 

Business business = new Business(businessEntityName) ; 

// Instanciation d'un contact. 

Contact contact = new Contact( "Paul SW-Dupond"); 

contact .setllseTypeC'Directeur" ) ; 

contact. addDescriptiontnew DescriptionC'Di rector SW-Aviation-XML" , "en")); 

contact. addDescriptiontnew DescriptionC'Di recteur SW-Aviation-XML", "fr")) 

// Ajout d'une adresse mail. 

Email email = new Email ("pswdupond@sw-aviation-xml .org") ; 

email .setUseTypet "not secure") ; 

contact .add Email (email ) ; 

// Ajout d'un numero de telephone. 

Phone phone = new Phone("+ 33 9 99 99 99 98"); 

phone. setUseTypet "office number") ; 

contact. add Phone (phone) ; 



// Ajout d'une adresse. 

String[] lines = new String[]{"2372, route de la Reine" 

"France"} ; 

Address address = new Addressd ines) ; 

address .setUseTypet "siege social ") ; 

cont act. addAddress( address) ; 



"78000 Versailles" 



// Affectation du contact a 1 
bus iness.addContactt contact) ; 



'entite metier. 



// Ajout des descriptions de l'entite metier. 

Description description = new DescriptionC'The travel at your finger tips. 

"en") ; 
business.addDescript ion (description) ; 

description = new DescriptionCLe voyage au bout des doigts", "fr"); 
business.addDescripti on (description) ; 
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II Categorisation de l'entite metier en "Information" (NAICS). 

// (voir http://www.naics.com pour plus de details) 

// (voir http://www.census.gov/epcd/naics/naicscod.txt pour la liste des 

codes) 
Category naics = new Categoryt "Information" , "51"); 
naics.setTModelKey(IUDDIConstants.UDDI_NAICS_UUID); 
bus iness.addCategory( naics) ; 

// Categorisation de l'entite metier en "Information Services and Data 

Processing Services" (NAICS). 
naics = new CategoryC'Information Services and Data Processing Services", 

"514"); 
naics.setTModelKey(IUDDIConstants.UDDI_NAICS_UUID); 
bus iness.addCategory( naics) ; 

// Categorisation de l'entite metier en "Data Processing Services" (NAICS). 
naics = new CategoryC'Data Processing Services", "5142"); 
naics.setTMode!Key(IUDDIConstants.UDDI_NAICS_UUID); 
bus iness.addCategory( naics) ; 

// Publication de l'entite metier, 
try { 

Business savedBusiness - uddi .saveBusiness(business) ; 

System. out. println("\nentite metier publiee\n" + savedBusiness); 
} 
catch (UDDIException e) { 

System. out. println("\nune exception " + e + " s'est produite : " + 
e.getDispositionReportO) ; 



} 

} 

La publication du modele abstrait du service de reservation aerienne sw-aviati on -xml -org : reserva- 
tion est ensuite realisee parle script TemplateModel .Java : 



import electri 

import electri 

import electri 

import electri 

import electri 

import electri 

import electri 



c.uddi .Category; 
c.uddi .Description; 
c.uddi . IUDDI; 
c.uddi . I UDDI Const ants ; 
c.uddi .Overview; 
c.uddi .TModel ; 
c.uddi .UDDIException; 



import electri c.uddi .client .UDDI CI ient; 
public class TemplateModel { 
public static void main(String[] args) throws Exception { 

String tModelName = "sw-aviation-xml -org:reservation" ; 

... acquisition parametres de connexion a l'annuaire UDDI ... 
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II Instantiation du client UDDI. 

IUDDI uddi = new UDDIC1 ient(inquireURL, publishURL, user, password); 

// Instantiation du service type de reservation. 
TModel tModel = new TModel (tModel Name) ; 

// Categorisation du service type en tant que specification WSDL. 
Category category = new Categoryt "uddi -org:types" , "wsdlSpec"); 
category. setTModel Key ( IUDDIConstants. UDDI_TYPE_TAXONOMY_NAME_UUID) ; 
tModel . addCategory( category) ; 

// Categorisation du service type en "On-Line Information Services" (NAICS). 
category = new Category("On-Line Information Services", "514191"); 
category. setTModel Key ( IUDDIConstants . UDDI_NAICS_UUID) ; 
tModel . addCategory( category) ; 

// Categorisation du service type en "Internet and intranet software" 

(UNSPSC). 
category = new CategoryC'Internet and intranet software", "431628"); 
category. setTModel Key ( IUDDIConstants. UDDMJNSPSCJJUID) ; 
tModel . addCategory( category) ; 

// Ajout des descriptions du service type. 

Description description = new DescriptionC'Travel reservation service", 

"en") ; 
tModel . addDescripti on (description) ; 

description = new DescriptionCService de reservation de voyages", "fr"); 
tModel .addDescripti on (description) ; 

// Affecte 1'URL de resume du service type. 

String url = "http://www.sw-aviation-xml .org:8080/reservation_sw-aviation- 

xml/services-type/ReservationService-interface.wsdl" ; 
description = new DescriptionCFichier de description WSDL du service de 

reservation de voyages.", "fr"); 
Overview overview = new OverviewCdescription, url); 
tModel .setOverview(overview) ; 

// Publication du service type, 
try { 

TModel savedTModel = uddi .saveTModel (tModel ) ; 

System. out. printlnt "\nservice type publie\n" + savedTModel); 
} 
catch (UDDIException e) { 

System. out. println( "\nune exception " + e + " s'est produite : " + 
e.getDispositionReportt )) ; 



} 

) 

Les deux scripts peuvent etre executes dans un ordre indifferent : BusinessEntity . java avant Tempi a- 
teModel .Java oul'inverse. 
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Le script Tempi ateModel .Java doit etre execute avantle script Bus inessService. Java de Fentite metier 
SW-Ai r car ce dernier a besoin de faire le lien avec le modele abstrait publie ici. 

Publication du point d'acces au service de reservation aerienne 

Ces scripts sont stockes dans le repertoire {%GLUE_HOME%}\scripts_SW-Air.com et permettent de 
publier Fentite metier SW-Ai r d'une part, et F implementation du modele abstrait du service de reser- 
vation aerienne sw-aviation-xml -org: reservation d' autre part. 

Le script BusinessEntity . java publie tout d'abord les coordonnees de Fentite metier SW-Ai r : 



mport electri 
mport electri 
mport electri 
mport electri 
mport electri 
mport electri 
mport electri 
mport electri 
mport electri 
mport electri 



c.uddi .Address; 
c.uddi .Business; 
c.uddi .Category; 
c.uddi .Contact; 
c.uddi .Description; 
c.uddi .Email ; 
c.uddi . IUDDI; 
c.uddi . I UDDI Const ants ; 
c.uddi .Phone; 
c.uddi .UDDI Exception; 



mport electri c.uddi .cl ient .UDDIC1 ient; 

public class BusinessEntity { 

public static void main( String[] args ) throws Exception { 

String businessEntityName = "SW-Air"; 

... acquisition parametres de connexion a l'annuaire UDDI ... 

// Instanciation du client UDDI. 

IUDDI uddi = new UDDIClientO'nquireURL, publishURL, user, password); 

// Instanciation de 1'entite metier. 

Business business = new Business(businessEntityName) ; 

// Instanciation d'un contact. 

Contact contact = new ContactC'Pierre SW-Durant"); 

contact. set UseType( "PDG" ) ; 

contact. addDescription(new DescriptionC'CEO SW-Air", "en")); 

contact .addDescription(new DescriptionC'PDG SW-Air", "fr")); 

// Ajout d'une adresse mail. 

Email email = new Email ("pswdurant@sw-air.com" ) ; 

email .setUseTypeC'not secure") ; 

contact .add Email (email ) ; 

// Ajout d'un numero de telephone. 

Phone phone = new Phone("+ 33 9 99 99 99 97"); 

phone. setUseTypeC off ice number") ; 
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contact .add Phone (phone) ; 

// Ajout d'une adresse. 

String[] lines = new String[]{"2645, place des metiers", "69000 Lyon", 

"France"} ; 
Address address = new Addressd ines) ; 
address . setUseTypet "siege social ") ; 
contact .addAddress( address) ; 

// Affectation du contact a l'entite metier. 
business.addContact( contact) ; 

// Ajout des descriptions de l'entite metier. 

Description description = new DescriptionC'The travel at your finger tips. 

"en") ; 
business.addDescript ion (description) ; 

description - new Description("Le voyage au bout des doigts", "fr"); 
business.addDescripti on (description) ; 

// Categorisation de l'entite metier en "Information" (NAICS). 

// (voir http://www.naics.com pour plus de details) 

// (voir http://www.census.gov/epcd/naics/naicscod.txt pour la liste des 

codes) 
Category naics = new Category( "Information" , "51"); 
naics.setTModelKey(IUDDIConstants.UDDI_NAICS_UUID); 
business.addCategoryt naics) ; 

// Categorisation de l'entite metier en "Information Services and Data 

Processing Services" (NAICS). 
naics - new Categoryt "Information Services and Data Processing Services", 

"514"); 
naics.setTModelKey(IUDDIConstants.UDDI_NAICS_UUID); 
business.addCategoryt naics) ; 

// Categorisation de l'entite metier en "Data Processing Services" (NAICS) 
naics = new Categoryt "Data Processing Services", "5142"); 
naics.setTModelKey(IUDDIConstants.UDDI_NAICS_UUID); 
business.addCategoryt naics) ; 

// Publication de l'entite metier, 
try { 
Business savedBusiness = uddi .saveBusiness(business) ; 
System. out. printlnt "\nentite metier publiee\n" + savedBusiness); 
} 

catch (UDDIException e) { 
System. out. println( "\nune exception " + e + " s'est produite : " + 
e.getDispositionReport( ) ) ; 
} 
} 
) 
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La publication de F implementation du modele abstrait du service de reservation aerienne sw-avi ati on- 
xml -org reservation est ensuite realisee par l'intermediaire du script Bus inessServ ice. Java : 



import 


electr 


c 


uddi 


.AccessPoint; 


import 


electri 


c 


uddi 


.Binding; 


import 


electri 


c 


uddi 


.Businesslnfos; 


import 


electri 


c 


uddi 


.Category; 


import 


electri 


c 


uddi 


.Description; 


import 


electri 


c 


uddi 


. IUDDI ; 


import 


electri 


c 


uddi 


.IUDDIConstants; 


import 


electri 


c 


uddi 


.Service; 


import 


electri 


c 


uddi 


.TModel Infos; 


import 


electri 


c 


uddi 


.TModel Instance; 


import 


electri 


c 


uddi 


.UDDIException; 


import 


electri 


c 


uddi 


.client. UDDIClient 



public class BusinessService { 
public static void main(String[] args) throws Exception { 

String tModelName = "sw-avi ati on-xml -org:reservation" ; 

String businessEntityName = "SW-Air"; 

... acquisition parametres de connexion a l'annuaire UDDI ... 

// Instanciation du client UDDI. 

IUDDI uddi = new UDDIC1 ientO'nquireURL, publishURL, user, password); 

// Recherche d'un service type dont le nom est specifie. 
TModellnfos tModel Infos = uddi .findTModels(tModelName, null); 

// Affichage des informations de chaque service type trouve. 
for(int i =0; i < tModel Infos. 1 ist. length; i++) { 

System. out. printlnC'tModel Infos " + i + " =\n" + tModel Infos. 1 ist[i ]) ; 
} 

// Selection de la cle du premier service type. 
String tModelKey = tModel Infos. 1 ist[0] .getTModel Key( ) ; 

// Recherche de la cle de la premiere entite metier dont le nom est 

specifie. 
Businesslnfos businesslnfos = uddi .findBusinesses(businessEntityName, null! 
String businessKey = businesslnfos.! ist[0] .getBusinessKey( ) ; 
System. out. pri ntl n( "businessKey = " + businessKey + "\n"); 

// Instanciation du service metier. 

Service service = new Servicet "Reservation") ; 

service. set Business Key (business Key) ; 

// Instanciation d'une liaison pour une implementation particuliere 
// du service de reservation de SW-Voyages. 
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Binding binding = new BindingO; 

TModel Instance tModel Instance = new TModel InstanceUModel Key) ; 

binding.addTModel Instance (tModel Instance) ; 

Description description = new DescriptionC'Access point for the reservation 

service implementation", "en"); 
binding.addDescripti on (description) ; 
description - new Description( "Point d'acces vers 1 ' implementation du 

service de reservation", "fr"); 
binding.addDescripti on (description) ; 
AccessPoint accessPoint = new AccessPointt 

"http://www.sw-air.com:8080/reservation_sw-air/servlet/rpcrouter" , 

"http"); 
binding.setAccess Point (access Point) ; 

// Ajout de la liaison au service metier, 
service. addBinding( binding) ; 

// Categorisation du service metier en "On-Line Information Services" 

(NAICS). 
Category category = new Category("On-Line Information Services", "514191"); 
category. setTModel Key ( IUDDIConstants . UDDI_NAICS_UUID) ; 
service. addCategory(category) ; 

// Categorisation du service metier en "Internet and intranet software" 

UNSPSC). 
category = new CategoryC'Internet and intranet software", "431628"); 
category. setTModel Key ( IUDDIConstants. UDDI_UNSPSC_UUID ) ; 
service. addCategory( category) ; 

// Ajout des descriptions du service metier. 

description - new Description( "Link to the reservation service", "en"); 

service. addDescripti on (description) ; 

description = new Description( "Lien vers le service de reservation", "fr"); 

service. addDescripti on (description) ; 

// Publication du service metier, 
try { 

Service savedService = uddi .saveService(service) ; 

System. out. println( "\nservice metier publie\n" + savedService); 
} 
catch (UDDIException e) { 

System. out. println( "\nune exception " + e + " s'est produite : " + 
e.getDispositionReport( ) ) ; 



) 



} 
} 

Les deux scripts doivent etre executes dans l'ordre qui suit 

1. BusinessEntity . Java ; 

2. BusinessService. Java. 
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Le script Bus inessService. Java doit etre execute apres le script Tempi ateModel .Java del'entite metier 
SW-Aviation-XML car il fait le lien avec le modele abstrait publie par cette entite. 

Publication du modele de reservation automobile 

Ces scripts sont stockes dans le repertoire {%GLUE_HOME%}\scripts_SW-Automobilisme-xml .org et 
permettent de publier Fentite metier SW-Automobilisme-XML d'une part (script BusinessEntity.java), 
et le modele abstrait du service de reservation automobile sw-automobilisme-xml -org: reservation 
d'autre part (script Tempi ateModel .Java). 

Les scripts ne sont pas reproduits ici car ils sont similaires a ceux du modele de reservation aerienne 
et n'apportent pas d'information supplementaire. 

Seules les informations qui suivent necessitent d'etre rappelees, pour une bonne comprehension de la 
suite du chapitre : 

• nom de 1' entite metier : SW-Automobilisme-XML ; 

• nom du modele abstrait : sw-automobilisme-xml -org reservation ; 

• URL de la description WSDL du service : http://www.sw-automobilisme-xml.org:8080/reservation_sw-auto- 
mobilisme-xml/services-type/ReservationService-interface.wsdl. 

Les deux scripts peuvent etre executes dans un ordre indifferent : BusinessEntity.java avant Templa- 
teModel .Java ou l'inverse. 

Le script Tempi ateModel .Java doit etre execute avant le script BusinessService. Java del'entite metier 
Sw-Voi tures car ce dernier a besoin de faire le lien avec le modele abstrait publie ici. 

Publication du point d'acces au service de reservation automobile 

Ces scripts sont stockes dans le repertoire {£GLUE_HOMEft}\scripts_SW-Voitures.com et permettent de 
publier Fentite metier SW-Voitures d'une part (script BusinessEntity.java), et 1' implementation du 
modele abstrait du service de reservation automobile sw-automobi 1 i sme-xml -org: reservation d'autre 
part. 

Les scripts ne sont pas reproduits ici car ils sont similaires a ceux du point d'acces au service de 
reservation aerienne. 

Seules les informations qui suivent necessitent d'etre rappelees : 

• nom de Fentite metier : SW-Voitures ; 

• nomdu modele abstrait implements : sw-automobilisme-xml -org reservation ; 

• URL du point d'acces au service metier : http://www.sw-voitures.com:8080/reservation_sw-voitures/servlet/ 
rpcrouter. 

Les deux scripts doivent etre executes dans 1' ordre qui suit : 

1. BusinessEntity.java ; 

2. BusinessService. Java. 

Le script BusinessService.java doit etre execute apres le script Tempi ateModel .Java del'entite metier 
SW-Automobi 1 i sme-XML car il fait le lien avec le modele abstrait publie par cette entite. 
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Publication du modele de reservation hoteliere 

Ces scripts sont stockes dans le repertoire {XGLUE_HOME£}\scripts_SW-Hotellerie-xml .org etpermet- 
tent de publier l'entite metier SW-Hotellerie-XML d'une part (script BusinessEntity.java), et le 
modele abstrait du service de reservation hoteliere sw-hotellerie-xml-org:reservation d'autre part 
(script Tempi ateModel .Java). 

Ces scripts ne sont pas reproduits ici car ils sont similaires a ceux du modele de reservation aerienne 
et automobile et n'apportent pas d' information supplementaire. 

Seules les informations qui suivent necessitent d'etre rappelees, pour une bonne comprehension de la 
suite du chapitre : 

• nomde l'entite metier : SW-Hotellerie-XML ; 

• nomdu modele abstrait : sw-hotellerie-xml -org : reservation ; 

• URL de la description WSDL du service : http://www.sw-hotellerie-xml.org:8080/reservation_sw-hotellerie- 
xml/services-type/ReservationService-interface.wsdl. 

Les deux scripts peuvent etre executes dans un ordre indifferent : BusinessEntity.java avant Tempi a- 
teModel .Java oul'inverse. 

Le script Tempi ateModel .Java doit etre execute avant le script Bus inessService. Java de l'entite metier 
SW-Hotel s car ce dernier a besoin de faire le lien avec le modele abstrait publie ici. 

Publication du point d'acces au service de reservation hoteliere 

Ces scripts sont stockes dans le repertoire {%GLUE_HOME%}\scripts_SW-Hotels.com et permettent de 
publier l'entite metier SW-Hotels d'une part (script BusinessEntity.java), et 1' implementation du 
modele abstrait du service de reservation hoteliere sw-hotellerie-xml -org: reservation d'autre part. 

Ces scripts ne sont pas reproduits ici car ils sont similaires a ceux du point d'acces au service de 
reservation aerienne ou au service de reservation automobile. 

Seules les informations qui suivent necessitent d'etre rappelees : 

• nom de l'entite metier : SW-Hotel s ; 

• nom du modele abstrait implemente : sw-hotellerie-xml -org: reservation ; 

• URL du point d'acces au service metier: http://www.sw-hotels.com:8080/reservation_sw-hotels/servlet/ 
rpcrouter. 

Les deux scripts doivent etre executes dans 1' ordre qui suit : 

1. BusinessEntity.java ; 

2. BusinessService. Java. 

Le script BusinessService. Java doit etre execute apres le script Tempi ateModel .Java de l'entite metier 
SW-Hotel 1 eri e-XML car il fait le lien avec le modele abstrait publie par cette entite. 

Publication du modele de reservation de voyage 

Ces scripts sont stockes dans le repertoire (KLUE_HOME%}\scripts_SW-Tourisme-xml .org et permet- 
tent de publier l'entite metier SW-Tourisme-XML d'une part (script BusinessEntity.java), et le modele 
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abstrait du service de reservation de voyage sw-tourisme-xml -org: reservation d'autre part (script 
Tempi ateModel .Java). 

Les scripts ne sont pas reproduits ici car ils sont similaires a ceux des modeles de reservation 
aerienne, automobile et hoteliere et n'apportent pas d' information supplementaire. 

Seules les informations qui suivent necessitent d'etre rappelees, pour une bonne comprehension de la 
suite du chapitre : 

• nom de l'entite metier : SW-Tourisme-XML ; 

• nom du modele abstrait : sw-tourisme-xml -org: reservation ; 

• URL de la description WSDL du service : http://www.sw-tourisme-xml.org:8080/reservation_sw-tourisme- 
xml/services-type/ReservationService-interface.wsdl 

Les deux scripts peuvent etre executes dans un ordre indifferent : BusinessEntity. java avant Templa- 
teModel .Java oul'inverse. 

Le script Tempi ateModel .Java doit etre execute avant le script Bus inessService. Java de l'entite metier 
Sw-Voyages car ce dernier a besoin de faire le lien avec le modele abstrait publie ici. 

Publication du point d'acces au service de reservation de voyage 

Ces scripts sont stockes dans le repertoire {KLUE_H0ME%}\scr1pts_SW-Voyages.com et permettent de 
publier l'entite metier Sw-Voyages d'une part (script BusinessEntity. Java), et 1' implementation du 
modele abstrait du service de reservation hoteliere sw-tourisme-xml -org: reservation d'autre part. 

Les scripts ne sont pas reproduits ici car ils sont similaires a ceux de publication du point d'acces aux 
services de reservation aerienne, automobile ou hoteliere. 

Seules les informations qui suivent necessitent d'etre rappelees : 

• nom de l'entite metier : SW-Voyages ; 

• nom du modele abstrait implements : sw-tourisme-xml -org: reservation ; 

• URL du point d'acces au service : http://www.sw-voyages.com:8080/reservation_sw-voyages/servlet/ 
rpcrouter. 

Les deux scripts doivent etre executes dans 1' ordre qui suit : 

1. BusinessEntity .java ; 

2. BusinessService. java. 

Le script Bus inessService. java doit etre execute apres le script Tempi ateModel .java de l'entite metier 
SW-Touri sme-XML car il fait le lien avec le modele abstrait publie par cette entite. 

Application Web de SW-Voyages 

Larborescence de l'application Web de la societe SW-Voyages (contexte reservation_sw-voyages) 
reste identique a celle du premier scenario, a l'exception des repertoires schemas et servi ces-type qui 
ont disparu au profit de l'application de l'organisation sectorielle SW-Tourisme-XML dont depend 
l'agence de voyages. 
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Partie serveur de I 'application Web de SW-Voyages 

Cette partie de 1' application Web de SW-Voyages est la seule a etre affectee par le passage a la 
seconde generation du systeme de reservation. Plus precisement, seule la classe d' implementation du 
service Web (classe ReservationService. Java) a subi des changements lies a la prise en compte de 
l'annuaire UDDI. 

Classe ReservationService.java 

Cette classe est essentiellement modifiee de maniere a utiliser une nouvelle classe Reservation- 
Finder, java dont l'objectif consiste a implementer la strategie de recherche des partenaires de SW- 
Voyages dans le cadre du processus de reservation. La classe implemente toujours les methodes 
suivantes (telechargez le code source sur www.editions-eyrolles.com) : 

• search : invoque successivement les trois services afin d'obtenir la reponse des partenaires. L'invo- 
cation de cette methode est le resultat de Faction n°l decrite dans la cinematique des echanges 
(figure 22-9) et declenchee par le script reservati on . j s decrit dans le chapitre 22. Cette invocation 
provoque 1' activation de la methode equivalente a destination des implementations des serveurs 
SW-Air, SW-H6tels et SW-Voitures. Ces dernieres invocations correspondent aux actions n°20, 22 
et 24 decrites dans la cinematique des echanges. Les numeros de reservation, renvoyes par ces trois 
serveurs, sont ensuite enregistres localement, ce qui correspond a la fin des actions n°21, 23 et 25. 

• book : invoque successivement les trois services afin d'obtenir la reponse des partenaires. Linvo- 
cation de cette methode est le resultat de Faction n°39 decrite dans la cinematique des echanges 
(figure 22-9) et declenchee parle script reservati on. js. Cette invocation provoque F activation de 
la methode equivalente a destination des implementations des serveurs SW-Air, SW-H6tels et SW- 
Voitures. Ces dernieres invocations correspondent aux actions n°40, 42 et 44 decrites dans la cine- 
matique des echanges. Les trois serveurs renvoient ensuite leurs reponses respectives, ce qui 
correspond a la fin des actions n°41, 43 et 45. 

• cancel : invoque successivement les trois services afin d'obtenir la reponse des partenaires. Linvo- 
cation de cette methode est le resultat de Faction n°39 decrite dans la cinematique des echanges 
(figure 22-9) et declenchee par le script reservati on .js. Cette invocation provoque Factivation de 
la methode equivalente a destination des implementations des serveurs SW-Air, SW-H6tels et SW- 
Voitures. Ces dernieres invocations correspondent aux actions n°40, 42 et 44 decrites dans la cine- 
matique des echanges. Les trois serveurs renvoient ensuite leurs reponses respectives, ce qui 
correspond a la fin des actions n°41, 43 et 45. 

• getAi rAvai labilities : invoque le service du partenaire de reservation aerienne afin d'obtenir ses 
disponibilites. Linvocation de cette methode est le resultat de Faction n°27 decrite dans la cinema- 
tique des echanges (figure 22-9) et declenchee par le script reservation. js. Cette invocation 
provoque Factivation de la methode equivalente a destination du serveur SW-Air qui correspond a 
Faction n°28 decrite dans la cinematique des echanges. Le serveur SW-Air renvoie ensuite ses 
disponibilites (action n°29), lesquelles sont enfin retournees au navigateur (action n°30). 

• getCarAvai 1 abi 1 1 11 es : invoque le service du partenaire de reservation automobile afin d'obtenir 
ses disponibilites. Linvocation de cette methode est le resultat de Faction n°31 decrite dans la 
cinematique des echanges (figure 22-9) et declenchee par le script reservation, js. Cette invoca- 
tion provoque Factivation de la methode equivalente a destination du serveur SW-Voitures qui 
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correspond a Taction n°32 decrite dans la cinematique des echanges. Le serveur SW-Voitures 
renvoie ensuite ses disponibilites (action n°33), lesquelles sont enfin retournees au navigateur 
(action n°34) : 

• getHotel Avail abilities : invoque le service du partenaire de reservation hoteliere afin d'obtenir 
ses disponibilites. L'invocation de cette methode est le resultat de Faction n°35 decrite dans la 
cinematique des echanges (figure 22-9) et declenchee par le script reservation, js. Cette invoca- 
tion provoque F activation de la methode equivalente a destination du serveur SW-H6tels qui 
correspond a Faction n°36 decrite dans la cinematique des echanges. Le serveur SW-H6tels 
renvoie ensuite ses disponibilites (action n°37), lesquelles sont enfin retournees au navigateur 
(action n°38) : 

Par ailleurs, la classe d'implementation du service Web presente toujours quelques methodes generiques 
particulieres : 

• invoke: methode d' invocation generique du service Web d' un partenaire. Cette methode encapsule 
les appels a FAPI de F implementation Apache SOAP. 

• getSchemaNamespace : cette methode est chargee de la recuperation de Fespace de noms associe au 
service Web d'un partenaire a partir de la description WSDL de son implementation. La methode 
est legerement modifiee par rapport a celle qui est decrite dans le premier scenario : en effet, la 
premiere version cherchait a recuperer la definition du premier import pour ensuite recuperer 
Fespace de noms du schema. Ici, cela n'est pas necessaire car la description WSDL dont Fadresse 
est passee en parametre est une description abstraite aupres de laquelle il est possible de recuperer 
directement Fespace de noms (methode getNamespaceURI). Cette methode fait appel au paquetage 
WSDL4J d'IBM. 

• getServi ceDef i ni ti on : cette methode a pour objet de recuperer la definition de service associee au 
service Web d'un partenaire a partir de la description WSDL de son implementation. Cette 
methode utilise egalement le paquetage WSDL4J d'IBM. 

La methode getServiceAccessPoint utilisee dans F implementation du premier scenario n'est plus 
necessaire. En effet, cette information est maintenant recuperee directement aupres de Fannuaire 
UDDI par Fintermediaire de la classe ReservationFinder.java. 

Cette classe effectue les recherches necessaires a Faide de Fannuaire UDDI dont PURL de FAPI de 
recherche est codee directement dans la variable UDDI_INQUIRE_URL de la classe ReservationSer- 
vice. Java : 

/* 

* URL de l'annuaire UDDI de reference. 
*/ 
private static String UDDI_INQUIRE_URL = 

"http://www.sw-registre-uddi .org:8004/glue/inquire/uddi" ; 

La variable UDDI_INQUIRE_URL pourrait bien entendu etre externalisee dans un fichier de configuration 
du service Web. II en va de meme pour les noms des trois modeles de services Web abstraits (aerien, 
automobile et hotelier) a rechercher dans l'annuaire UDDI : 

I 

* Nom du service type de reservation aerienne. 

*/ 
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private static String AIR_TMODEL_NAME - "sw-aviation-xml -org:reservation" ; 

/* 

* Norn du service type de reservation automobile. 

*/ 

private static String CAR_TMODEL_NAME - "sw-automobil isme-xml -org: reservation" ; 



* Norn du service type de reservation hotel iere. 
*/ 
private static String HOTEL_TMODEL_NAME ■ "sw-hotellerie-xml-org:reservation" ; 

L' acquisition des URL des points d'acces aux implementations des partenaires et des espaces de 
noms correspondants est realisee dans le constructeur de la classe ReservationService. java. Cette 
methode implemente toutes les actions de liaison avec l'annuaire UDDI, c'est-a-dire les actions n°2 
a n°19 decrites dans la cinematique des echanges (figure 22-9) : 

/* 

* Le constructeur du service de reservation. Recupere, 

* via l'annuaire UDDI, les URL d'acces aux services 

* de reservation des partenaires, ainsi que les espaces 

* de noms associes aux schemas des services abstraits 

* implemented par les partenaires. 
*/ 
public ReservationService( ) throws ReservationException { 

String[] parameters = getFinder( ) . 1 ookup( UDDI_INQUI RE_URL . AI R_TMODEL_NAME) ; 
setAirSchemaNamespace(getSchemaNamespace(parameters[0])) ; 
setAirServiceAccessPoint(parameters[l]) ; 

parameters = getFinder( ) .lookup(UDDI_INQUIRE_URL, CAR_TMODEL_NAME) ; 
setCarSchemaNamespace(getSchemaNamespace(parameters[0])) ; 
setCarServiceAccessPoint(parameters[l]) ; 

parameters = getFinder( ) .lookup(UDDI_INQUIRE_URL, HOTEL_TMODEL_NAME) ; 
set Hotel SchemaNamespace(getSchemaNamespace( pa rameters[0] ) ) ; 
setHotelServiceAccessPointt parameters [1] ) ; 
} 

Enfin, la methode getSOAPMappingRegistry est toujours presente dans cette implementation, elle 
prend en charge la declaration des mappers necessaires a la conversion des types complexes 
AirAvai lability, CarAvai lability et Hotel Avail ability. Ceux-ci utilisent les services de serialisation/ 
deserialisation de la classe generique BeanSerializer.java presente dans 1' implementation Apache 
SOAP: 

private synchronized SOAPMappingRegistry getSOAPMappingRegistryt ) 
throws ReservationException { 
if (smr==nul 1 ) { 

smr = new SOAPMappingRegistry( ) ; 

BeanSerial izer bs - new BeanSerial izer( ) ; 

smr. mapTypes( Constants. NS_URI_SOAP_ENC , 
new QName(getAi rSchemaNamespace( ) , "Ai rAvailabil ity") , 
AirAvailabil ity. class, bs, bs); 
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smr.mapTypes( Constants. NS_URI_SOAP_ENC , 
new QName(getCarSchemaNamespace( ) , "CarAvailabil ity") , 
CarAvailabil ity. class, bs, bs); 
smr.mapTypes( Constants. NS_URI_SOAP_ENC, 
new QName(getHotelSchemaNainespace( ) , "Hotel Availabil ity") , 
Hotel Availabil ity .cl ass , bs, bs); 
} 

return smr; 
} 

Classe ReservationFinder.java 

Cette nouvelle version du service Web Java de SW- Voyages ne recherche done plus les URL des 
points d'acces aux implementations des services Web des partenaires dans les fichiers de description 
WSDL associes a ces services. 

Au lieu de cela, la recherche est realisee par F intermediate de Fannuaire UDDI dont Fadresse est 
referencee dans la variable statique UDDI_INQUIRE_URL Toute la logique d'acces a cet annuaire est 
implementee dans une nouvelle classe ReservationFinder.java. La classe d' implementation du 
service Web fait appel a cette classe pour recuperet - deux informations importantes (voir le constructeur 
de la classe ReservationService. Java) : 

• FURL de la description WSDL du service type implemente ; 

• FURL du point d'acces a F implementation d'un partenaire. 

La classe ReservationFinder.java est la seule classe qui ait besoin d'implementer FAPI d'acces (en 
mode recherche uniquement) a Fannuaire UDDI du produit Glue. 

La strategie de recherche de partenaires implementee pour notre exemple est minimale : 

1. La classe recherche tout d'abord la collection des services types dont le nom est passe en parametre : 

- sw-aviation-xml-org:reservation pour le modele de la reservation aerienne (voir la variable 
AIR_TMODEL_NAME de la classe ReservationService. Java) ; 

- sw-automobilisme-xml -org: reservation pour le modele de la reservation automobile (voir la 
variable CAR_JMODEL_NAME de la classe ReservationService. Java) ; 

- sw-hotellerie-xml -org: reservation pour le modele de la reservation hoteliere (voir variable 
HOTEL_TMODEL_NAME de la classe ReservationService. Java). 

2. Parmi les services types trouves, la classe en choisit un au hasard et recherche la collection des 
entites metier qui F implementent. 

3. Parmi les entites metier trouvees, la classe en choisit une au hasard et recherche la collection des 
services metier de cette entite metier qui implementent le service type selectionne. 

4. Parmi les services metier trouves, la classe en choisit un au hasard et recherche la collection des 
liaisons de ce service metier qui implementent le service type selectionne. 

5. Parmi les liaisons trouvees, la classe en choisit une au hasard et recherche le point d'acces corres- 
pondant, ainsi que la description WSDL du service type implemente. 

L implementation de la classe ReservationFinder.java est presentee dans le code source que vous 
pouvez telecharger sur www.editions-eyrolles.com. 
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Applications Web des partenaires de SW-Voyages 

Par rapport ail premier scenario, les applications Web deployees par les partenaires sont inchangees 
et demeurent strictement identiques aux versions de la premiere generation. Seuls les descripteurs de 
deploiement ont ete modifies pour refleter le changement de Fespace de noms associe aux types de 
donnees serialises passes sous le controle des organismes sectoriels. 

Le developpement de la deuxieme generation du service Web de reservation de SW-Voyages n'aura 
done eu qu'un impact extremement limite sur les systemes d'information de ses pailenaires. 

Partie serveur de I'application Web des partenaires de SW-Voyages 

II n'y a aucun changement par rapport au premier scenario (voir precedemment). 
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Ce chapitre est le second de la partie consacree a la presentation d'une architecture de service dynami- 
que. Cette implementation s'appuie toujours sur l'exploitation d'un annuaire UDDI pour decouvrir a 
F execution les points d'acces des services de reservation des partenaires de SW- Voyages. 

Conformement aux nouveaux choix technologiques de SW- Voyages, cette troisieme generation du 
logiciel de reservation s'appuie maintenant sur la plate-forme technologique .NET de Microsoft. 

Cette troisieme generation du logiciel de reservation correspond au scenario n°3 presente chapitre 22. 

Implementation 

Le deploiement des composants applicatifs sur les plates-formes techniques de chacun des partenai- 
res (commerciaux et organisations sectorielles) est maintenu sous forme d'installation duplications 
Web : en technologie .NET pour SW- Voyages et Java pour ses partenaires (statu quo). 

Produits utilises 

Les produits utilises dans ce troisieme scenario sont identiques a ceux qui ont ete mis en ceuvre dans 
le deuxieme scenario. 

A cette liste de produits utilises, il convient cependant d'ajouter les produits specifiques a la plate-forme 
de Microsoft qui remplace la plate-forme Java precedemment mise en ceuvre par SW- Voyages : 

• Internet Information Server 5.0 ; 

• Visual Studio.NET 7.0 ; 

• UDDI.NET SDK 1.76 beta. 
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Microsoft Internet Information Server (IIS) 5.0 

Le serveur HTTP de Microsoft est installe en standard dans tous les serveurs Windows 2000 (voir 
http://www.microsoft.com/windows2000/technologies/web/default.asp). II est egalement disponible dans la 
version Windows 2000 Professional en nombre limite de connexions. 

Le repertoire de publication des applications Web par defaut utilise par IIS 5.0 est le repertoire 

C: \Inetpub\wwwroot. 

Dans la suite de la migration vers la technologie Microsoft, ce repertoire d' installation des applications 
IIS sera designe par la variable {%INET_H0ME%}. 

Microsoft Visual Studio.NET 7.0 

Le Visual Studio.NET constitue la derniere evolution de F atelier de developpement de Microsoft. 
Cette nouvelle declinaison, comme son nom l'indique, fonctionne de maniere integree avec le 
framework .NET. 

Cet environnement de developpement n'est pas vraiment necessaire pour realiser le portage vers la 
technologie .NET et plus particulierement vers le langage C#. Les outils presents dans le framework 
.NET, dont le compilateur csc.exe, auraient ete suffisants. Cependant, cette plate-forme est utilisee 
ici du fait de son maniement tres simple. 

Les ressources relatives a ce produit sont accessibles a http://msdn.microsoft.com/vstudio/default.asp. 

La version de F environnement de developpement utilisee ici est Visual Studio.NET 7.0 (MSDE 
2002) et s'appuie sur le framework .NET en version 1.0.3705. 

Par defaut, Visual Studio.NET installe les nouveaux projets dans le repertoire C:\Documents and 
Settings\userId\Mes documents\Projets Visual Studio (sous Windows 2000), oil userld correspond 
au nom du compte utilise pour ouvrir la session Windows. 

Dans la suite de la migration vers la technologie Microsoft, le repertoire d' installation des projets 
Visual Studio.NET sera designe par la variable {%PNET_H0ME%}. 

Microsoft UDDI.NET SDK 1.76 beta 

Le SDK UDDI.NET fournit une implementation de FAPI cliente UDDI. La version 1.76 beta imple- 
mente la version 1 .0 de la specification UDDI. 

Les ressources relatives a ce produit sont disponibles sur le site MSDN a Fadresse http://msdn. micro- 
soft. com/library/default.asp?uri=/downloads/list/websrvuddi. asp. 

Parametrage des produits 

Apres F installation de ces trois produits, aucune adaptation particuliere n'est necessaire en termes de 
parametrage des produits. 
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Developpement 

La cinematique des echanges entre les serveurs, decrite chapitre 22 (voir la section « Scenario n°2 »), 
est exactement identique a celle qui est mise en ceuvre dans ce scenario. 

Notons plus particulierement que le deploiement des modeles et services du systeme de reservation a 
destination de Fannuaire UDDI, realise dans le chapitre precedent, demeure inchange. Aucune modi- 
fication des informations publiees ni, a fortiori, aucun redeploiement ne sont necessaires. 

Application Web de SW-Voyages 

Du fait du changement d'environnement technologique decide par la societe SW-Voyages, cette 
application Web doit etre entierement remplacee : nous sommes dans une situation de migration par 
portage du code existant de la plate-forme Java vers la plate-forme .NET. II s'agit plus precisement 
d'une refonte technologique (de Java/Tomcat a C#/.Net/IIS) qui laisse inchange le comportement 
fonctionnel de F application. 

Migration de /'application Web de SW-Voyages vers le framework .NET 

La migration de cette application Web sera effectuee manuellement par un portage du contenu de 
1' application Java vers une application .NET Cette application .NET sera decomposed en deux 
projets : 

• un premier projet de type application Web ASP.NET pour implementer F equivalent de la partie 
cliente de F application Java ; 

• un second projet de type service Web ASP.NET pour reprendre la partie serveur de F application 

Java. 

La gestion de ces deux projets sera prise en charge par Fenvironnement de developpement Visual 
Studio.NET 7.0 de Microsoft (MSDE 2002), lequel s'appuie sur le framework .NET 
(version 1 .0.3705). Le deploiement sera realise sur la version limitee du serveur IIS 5.0 de Microsoft, 
integree dans le systeme d' exploitation Windows 2000 Professional. 



Utilisation de Windows 2000 Server 

Pour realiser des developpements logiciels consequents, il faut plutot disposer d'une version serveur de Windows 
2000. En effet, la limite maximale du nombre de connexions au serveur IIS est rapidement atteinte et se traduit par 
I'apparition de I'erreur HTTP 403.9. Cela necessite alors un redemarrage du serveur IIS, ce qui, a la longue, 
devient fastidieux. 



Migration de la partie cliente de I'application Web de SW-Voyages 

Creation de I'application Web dans Visual Studio.NET 

La partie cliente est transposed dans une application Web ASP.NET. Cette nouvelle application est 
creee par le menu Fi 1 e>New>Bl ank Sol uti on... de Visual Studio.NET La boite de dialogue presentee 
permet de saisir le nom de I'application (SW-Voyages) et le repertoire d' installation (C : \Documents and 
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Settings\userId\Mes documents\Projets Visual Studio, par exemple sous Windows 2000) de la 
nouvelle application .NET. 

A partir de la fenetre Solution Explorer, selectionnez la nouvelle solution creee SW-Voyages et 
creer un nouveau projet par le menu Add>New Project.... Dans la boite de dialogue presentee, selec- 
tionnez ensuite un projet de type Visual C# Projects, puis le modele ASP.NET Web Appl ication et 
enfin saisissez l'URL d'acces au nouveau projet http://localhost/reservation_sw-voyages. Cela a pour 
effet de creer un sous-repertoire reservation_sw- voyages dans le repertoire C:\Inetpub\wwwroot du 
serveur IIS. 

Dans l'explorateur de solution, selectionnez alors le nouveau projet cree reservation_sw-voyages 
et creez de nouveaux dossiers viale menu Add>New Folder nommes images, scripts et services. 

Duplication des ressources de I'application Java vers I'application .NET 

A partir de I'application deployee dans le serveur d' applications Java, il faut ensuite dupliquer les 
ressources vers le repertoire du projet .NET, c'est-a-dire : 

• copier {%TOMCAT_HOME%}\webapps\reservation_sw-voyages\avai labilities. html vers 
{%INET_HOME%}\reservation_sw-voyages\avai labilities. html ; 

• copier {HOMCATJOME%}\webapps\reservation_sw-voyages\content.html vers {XINET_H0ME£}\ 
reservation_sw-voyages\content . html ; 

• copier {%TOMCAT_HOME%}\webapps\reservation_sw-voyages\footer.html vers {%I NET_H0ME%} \ 
rese r va tion_sw-voy ages \ footer. html ; 

• copier {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\header.html vers {%INET_H0ME%} \ 
rese r va t ion_sw-voy a ges\ header. html ; 

• copier {UOMCATJOMEXl\webapps\reservatiorusw-voyages\index.html vers {%INET_H0ME%} \ 
reservation_sw-voyages\index.html ; 

• copier {%TOMCAT_HOME%}\webapps\reservation_sw-voyages\reservation.html vers 
{%INET_HOME%}\reservation_sw-voyages\reservation. html . 

II faut egalement dupliquer les ressources des sous-repertoires Tomcat vers les sous-repertoires equi- 
valents du projet .NET, c'est-a-dire : 

• copier {%TOMCAT_HOME%}\webapps\reservation_sw-voyages\images\blanc.gif vers 
mNET_HOME%}\reservation_sw-voy ages \i mages \bl anc.gif ; 

• copier {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\images\fond.jpg vers 
{%INETJOME%}\reservation_sw- voyages \images\fond.jpg ; 

• copier {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\scripts\reservation. js vers 
mNET_HOME%}\reservation_sw- voyages \scripts\reservati on . js ; 

• copier {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\scripts\style.css vers 
{%INET_HOME%}\reservation_sw- voyages \scripts\styl e. ess ; 

• copier {%TOMCAT_HOME£}\webapps\reservation_sw-voyages\scripts\webservice.htc vers 
mNET_HOME%}\reservation_sw- voyages \scripts\webservi ce. htc ; 

• copier {%TOMCAT_HOME%}\webapps\reservati on_sw- voyages \services\ Reservati onSer- 
vi ce.wsdl vers mNET_H0ME%}\ reservati on_sw-voyages\services\ReservationServi ce.wsdl . 
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Integration des ressources de I'application dans Visual Studio.NET 

Apres avoir duplique les ressources de I'application Web Java, il faut les integrer dans le projet .NET. 

Dans l'explorateur de solution, selectionnez le projet reservation_sw-voyages et ajoutez-y les 
fichiers dupliques par le menu contextuel Add>Add Existing Item.... Dans la boite de dialogue, 
selectionnez ensuite l'ensemble des fichiers precedemment dupliques (availabilities.html, 
content.html, footer.html, header.html, index.html et reservation.html) afin de les ajouter en 
une seule fois. 

Puis, faites de meme avec les sous-repertoires images, scripts et services du projet 
reservation_sw-voyages (meme commande par le menu contextuel de ces sous-repertoires: 
Add>Add Existing Item...). 

Modification de I'adresse d'acces a la description WSDL dans le code JavaScript 

Enfin, il ne reste plus qu'a modifier I'adresse de la description WSDL du service de reservation : 
pour cela, modifiez la variable JavaScript RESERVATION„WSDL_URL du fichier {%INET_H0ME%} \ 
reservation_sw-voyages\scripts\reservation. js en supprimant le port 8080 utilise par l'imple- 
mentation Java : 



Iva 



r RESERVATION_WSDL_URL = "http://www.sw-voyages.com/reservation_sw-voyages/services/ 
ReservationService.wsdl" ; 



Sauvegarde de I'application Web dans Visual Studio.NET 

A ce stade, la transformation de la partie cliente de I'application Web Java en application Web .NET 
est terminee. 

II est possible de supprimer deux ressources inutilisees par I'application : 

• dans l'explorateur de solution, selectionnez le fichier WebForml.aspx du projet reservation_sw- 
voyages et supprimez-le par le menu contextuel Del ete (fichier genere par defaut a la creation du 
projet et inutilise dans cette etude de cas) ; 

• dans l'explorateur de solution, selectionnez le repertoire Sol uti on Items de la solution SW-Voyages 
et supprimez-le via le menu contextuel Remove ; 

II ne reste plus qu'a sauvegarder I'application : a partir de la fenetre Sol uti on Expl orer, selectionnez 
la solution SW-Voyages et sauvegardez tout par le menu contextuel Save Al 1 . 

Au final, le contenu de la fenetre de l'explorateur de la solution SW-Voyages doit ressembler a celui 
illustre figure 25-1. 

Test de I'application Web .NET 

Afin de verifier que tout fonctionne correctement, il suffit de tester I'application : 

• soit directement a partir de l'environnement de developpement ; 

• soit hors de l'environnement de developpement, a partir du navigateur Internet Explorer. 
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Figure 25-1 

Arborescence de la solution ASP.NET SW-Voyages. 



Voici la procedure a suivre pour tester directement a partir de Fenvironnement de developpement : 

1. Demarrez le serveur Tomcat pour utiliser la partie serveur de 1' application Web Java. 

2. Dans l'explorateurde solution, selectionnez le fichier index.html duprojet reservation_sw-voya- 
ges et selectionnez-le en tant que page initiale de F application par le menu contextuel Set As 
Start Page. 

3. Lancez l'application par le menu Debug>Start Wi thout Debuggi ng : ceci a pour effet de lancer la 
construction de l'application (build), puis d'ouvrir une fenetre du navigateur sur FURL http://local- 
host/reservation_sw-voyages/index.html. 

Voici maintenant la procedure a suivre pour tester directement a partir du navigateur : 

1. Demarrez le serveur Tomcat pour utiliser la partie serveur de l'application Web Java. 

2. A partir de la fenetre Sol uti on Expl orer, selectionnez la solution SW-Voyages et lancez la construc- 
tion par le menu contextuel Build Solution. 

3. Ouvrez une fenetre du navigateur en la faisant pointer vers FURL http://www.sw-voyages.com/ 
reservation_sw-voyages/index.html (attention : sans le port 8080 qui pointe vers la partie cliente de 
Tomcat). 

Dans cette configuration, la partie cliente de l'application de reservation, servie par le serveur Web 
IIS de Microsoft, communique en protocole SOAP sur HTTR avec la partie serveur de l'application, 
hebergee par le serveur Tomcat d' Apache. 
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A ce stade du portage, nous disposons done de deux applications clientes capables d' exploiter simul- 
tanement les services offerts par le serveur d' applications Java de SW- Voyages : 

• un client (deploye par un serveur) Java, issu du premier scenario ; 

• un client (deploye par un serveur) .NET strictement equivalent, issu du portage. 

II faut remarquer que le code de la partie cliente de 1' application Web est strictement identique entre 
la version deployee dans le serveur Java Tomcat lors du premier scenario et celle qui est maintenant 
installee dans le serveur US, a l'exception de l'adresse de la description WSDL du service de reser- 
vation utilisee dans le fichier JavaScript (changement du port 8080 de Tomcat vers le port 80 dTIS). 

Modifications du point d'acces au service et du client JavaScript (acces au service .NET) 

Ann de preparer la partie cliente a fonctionner avec un partie serveur deployee sur le framework 
.NET, il est necessaire d'effectuer deux modifications complementaires : 

1. Changez FURL du point d'acces a F implementation en C# dans la description du service (fichier 
{ftINET_HOMEI}\reservation_sw-voyages\services\ReservationService.wsdl). La valeurde Fattribut 
location devient : 

<service name="ReservationService"> 
<port binding="interface:ReservationService" name="ReservationService"> 
<soap:address 
1 oca tion=" http://www.sw- voyages.com/reservation_service_sw- 
voyages/ReservationService.asmx"/> 
</port> 
</service> 

2. Modifiez la recuperation des disponibilites aeriennes, automobiles ou hotelieres dans le code 
JavaScript de la partie cliente (fichier mNET_HOME$}\reservation_sw-voyages\script\reserva- 
tion.js) en remplacant dans les fonctions get_airAvailabilities_callback, get_carAvaila- 
bilities_callback et getJiotelAvailabil ities_cal lback, la ligne : 

var availabilities = result. raw. getElementsByTagNameC'item") ; 

par le code : 

var availabilities - new ArrayO; 

var nodes = result. raw. parentNode. selectNodes("//Item/@href") ; 

for (i =0; i < nodes. length; 1++) { 

var availability = result. raw. parentNode. selectSingleNode( 
'7/*[@id='"+nodes[i ] .nodeVal ue. spl i t( "#" ) [1]+" ' ] " ) ; 

availabil ities[i ] = availability; 



Difference de serialisation/deserialisation par defaut entre les frameworks Java et .NET 

Cette derniere adaptation est indispensable du fait que la structure du document XML renvoye par le 
service Web C# (serialisation par defaut) fait appel aux mecanismes de referencement du style de 
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codage SOAP 1.1 (liens id/href). Par exemple, l'invocation de la methode getAirAvai labilities se 
traduit par une reponse SOAP de la forme : 

HTTP/1.1 200 OK 

Server: Microsoft-IIS/5.0 

Date: Sat, 16 Nov 2002 14:59:48 GMT 

Cache-Control: private, max-age=0 

Content-Type: text/xml ; charset=utf-8 

Content-Length: 5231 

<?xml version="1.0" encoding="utf-8"?> 
<soap:Envelope 

xmlns :soap=" http://schemas.xml soap.org/soap/envel ope/" 

xmlns:soapenc=http://schemas.xml soap.org/soap/encoding/ 

xmlns :tns="http://tempuri .org/" 

xmlns :types="http://tempuri .org/encodedTypes" 

xmlns :xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xmlns :xsd=" http://www.w3.org/2001/XMLSchema"> 
<soap:Body soap :encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 
<ql : getAi rAvai 1 abi 1 itiesResponse xmlns:ql="urn:ReservationService"> 

<return href="#idl" /> 
</ql: getAi rAvai 1 abi 1 itiesResponse> 
<soapenc:Array id="idl" 

xmlns:q2="http://www.sw-aviation-xml . org:8080/reservation_sw-aviation- 
xml/schemas/ReservationService- schema" 

soapenc:arrayType="q2:Ai rAvai lability [6] "> 

<Item href="#1d2" /> 

<Item href="#id3" /> 

<Item href="#id4" /> 

<Item href="#id5" /> 

<Item href="yMd6" /> 

<Item href="#id7" /> 
</soapenc:Array> 
<q3: Ai rAvai 1 abi 1 ity id="id2" xsi :type="q3:Ai rAvai 1 abi 1 ity" 

xmlns:q3="http://www.sw-aviation-xml . org:8080/reservation_sw-aviation- 
xml/schemas/ReservationService- schema "> 

<id xsi:type="xsd:int">1951575647</id> 

<airCompany xsi :type="xsd:string">SW Luft Austria</ai rCompany> 

<fl ightNumber xsi :type="xsd:string">LA2365</fl ightNumber> 

<departureAirport xsi :type="xsd:string">Paris-CDG</departureAirport> 

<arri val Ai rport xsi :type="xsd:string">Vienne</ar rival Ai rport> 

<departureHour xsi :type="xsd:string">07hl5</departureHour> 

<arri val Hour xsi :type="xsd:string">09hl5</arrivalHour> 

<di recti on xsi :type="xsd:boolean">true</direction> 

<price xsi :type="xsd:float">1240</price> 

<remoteId xsi :type="xsd:int">-1557482178</remoteId> 
</q3:Ai rAvai 1 abi 1 ity> 

<q8:Ai rAvai 1 abi 1 ity id="id7" xsi :type="q8:Ai rAvai 1 abi 1 ity" 

</q8:Ai rAvai 1 abi 1 ity> 
</soap:Body> 
</soap: Envelope> 
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En revanche, le resultat de la meme invocation renvoye par 1' implementation Java se presente ainsi : 

HTTP/1.1 200 OK 

Content-Type: text/xml ; charset=utf-8 

Content-Length: 4337 

Date: Sat, 16 Nov 2002 15:18:52 GMT 

Server: Apache Coyote/1.0 

Connection: close 

<?xml version^' 1.0' encoding='UTF-8'?> 
<S0AP-ENV:Envelope 
xml ns : SOAP- EN V=" http://schemas.xml soap.org/soap/envelope/" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns:xsd=" http://www.w3.org/2001/XMLSchema"> 
<SOAP-ENV:Body> 

<nsl :getAi r Avail abil itiesResponse 
xmlns:nsl="urn:ReservationService" 

SOAP- ENV:encodingStyle=" http://schemas.xml soap.org/soap/encoding/"> 
<return 
xml ns:ns2=" http://schemas.xml soap.org/soap/encoding/" 
xsi :type="ns2:Array" 
xmlns:ns3="http://www.sw-aviation-xml .org: 8080/ reservation_sw-aviation- 

xml /schema s/ReservationService -schema" 
ns2 : a rrayType="ns3:AirAvai lability [6] "> 
<item xsi :type="ns3:Ai rAvailabil ity"> 
<airCompany xsi :type="xsd:string">SW Luft Austria</ai rCompany> 
<arrivalAi rport xsi :type="xsd:string">Vienne</arrival Airport > 
<arrivalHour xsi :type="xsd:string">09hl5</arrivalHour> 
<departureAi rport xsi :type="xsd:string">Paris-CDG</departureAirport> 
<departureHour xsi :type="xsd:string">07hl5</departureHour> 
<di recti on xsi :type="xsd:boolean">true</direction> 
<fl ightNumber xsi :type="xsd:string">LA2365</fl ightNumber> 
<id xsi:type="xsd:int">-134743094</id> 
<price xsi :type="xsd:float">1240.0</price> 
<remoteId xsi :type="xsd:int">-869333497</remoteId> 
</item> 

<item xsi :type="ns3:Ai rAvailabil ity"> 

</item> 
</return> 
</nsl : getAi rAvai 1 abi 1 i ti esResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

Bien entendu, cette difference entre les implementations Java et C# pourrait etre gommee si nous 
n'utilisions pas la serialisation standard offerte par l'un des frameworks, d'un cote ou de 1' autre, et si 
nous developpions une classe de serialisation dont le resultat serait en phase avec celui qui est produit 
par 1' autre framework. Ceci permettrait de compenser la petite modification effectuee precedemment 
dans le code de la partie cliente de F application. 
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Cette modification est un exemple du type de problemes d'interoperabilite qui peuvent surgir lors de 
l'utilisation du style de codage SOAP 1.1 : des options de codage valables (selon le style SOAP 1.1) 
mais differentes, pour des messages definis dans la meme interface WSDL, ne sont pas totalement 
masquees au niveau technique et se repercutent au niveau applicatif. 

Migration de la partie serveur de I'application Web de SW-Voyages 

La partie serveur est transposee dans un service Web ASP.NET. Ce nouveau service est cree par le 
menu File>New>Blank Solution... de Visual Studio.NET. La boite de dialogue presentee permet de 
saisir le nom de I'application (SW-Voyages Reservation) et le repertoire d' installation (C:\Documents 
and Settings\userId\Mes documents\Projets Visual Studio, par exemple sous Windows 2000) du 
nouveau service .NET 

A partir de la fenetre Solution Explorer, selectionnez la nouvelle solution creee SW-Voyages Reser- 
vation et creez un nouveau projet par le menu Add>New Pro j ect... Dans la boite de dialogue presentee, 
selectionnez un projet de type Visual C# Projects, puis le modele ASP.NET Web Service et enfin 
saisissez FURL d'acces au nouveau projet http://localhost/reservation_service_sw-voyages. Ceci a pour 
effet de creer un sous-repertoire reservation_service_sw-voyages dans le repertoire C:\Inetpub\ 
wwwroot du serveur IIS. 

A partir de I'application deployee dans le serveur d'applications Java, il faut ensuite dupliquer les 
ressources vers le repertoire du projet .NET, c'est-a-dire copier les fichiers {%T0MCAT_H0ME%}\ 
webapps\ reservati on„sw-voyages\WEB- I NF\cl a s ses\com\swvoy ages \ reservation^. Java (sauf le 
fichier ReservationService.java) en modifiant au passage l'extension vers {%I NET_H0ME%} \ 
reservation_service_sw-voyages\*.cs. 

Apres avoir duplique les ressources de I'application Web Java, il faut les integrer dans le projet 
.NET: dans l'explorateur de solution: selectionnez pour cela le projet reservati on_service_sw- 
voyages et ajoutez-y les fichiers dupliques par le menu contextuel Add>Add Existing Item.... Dans la 
boite de dialogue, selectionnez l'ensemble des fichiers precedemment dupliques (AirAvai labi- 
lity. cs, CarAvailability.es, HotelAvailability.es, Reservation.es, IReservationService.es, 
ReservationException.es, ReservationManager.es et ReservationRegistry.es) afin de les ajouter en 
une seule fois. 

Generation du squelette du service de reservation 

En ce qui concerne la classe ReservationService.java, l'outil wsdl .exe du framework .NET permet 
de generer le squelette (skeleton) equivalent a partir de la description WSDL du service de reservation. 
Voici la procedure a suivre : 

1. Renommez la classe Servi eel . asmx generee automatiquement par defaut lors de la creation du projet 
en ReservationService.asmx : dans l'explorateur de solution, selectionnez le fichier Servi eel. asmx 
du projet reservati on_servi ce_sw-voyages et renommez-le via le menu contextuel Rename. 

2. Modifiez la directive WebServi ce : a l'aide d'un editeur texte (Notepad par exemple), modifiez le 
contenu du fichier mNET_HOME$}\reservation_service_sw- voyages \ReservationService. asmx en 
remplacant le nom de la classe genere initialement par : 

I<%@ WebService Language="c#" Codebehind="ReservationService. asmx.es" 
CI as s=" com. swvoyages. reservati on. Reservati onService" %> 
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3. Modifiez le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-tourisme-xml\services-type\ 
ReservationService-interface.wsdl pour attribuer des valeurs aux attributs soapAction des balises 
operation, telles que : 

<soap: operation soapAction="urn:ReservationService/cancel"/> 

<soap: operation soapAction="urn:ReservationService/book"/> 

<soap: operation soapAct ion= "urn :ReservationService/getAirAvai labilities"/) 

<soap: operation soapAction= "urn :ReservationService/getCarAvai labilities"/) 

<soap: operation soapAction="urn:ReservationService/getHotelAvailabil ities"/> 

<soap: operation soapAction="urn:ReservationService/search"/> 

4. Demarrez le serveur Tomcat pour utiliser la partie serveur de 1' application Web Java. 

5. Generez le contenu du fichier ReservationService.asmx.es (Codebehind), via une fenetre 
d'invite de commandes, par la commande : 

wsdl 

/out:C:\Inetpub\wwwroot\reservation_service_sw-voyages\ReservationService.asmx.cs 

/namespace: com. swvoy ages. reservation 

/server 

http:/ /www. sw- voyages. com: 8080/ reservation_sw-voyages/services/ReservationService. wsdl 

Apres integration des fichiers d'origine Java dans le projet .NET, il faut realiser le portage en syntaxe 
C# proprement dit. Ce transcodage peut etre realise soit manuellement, soit a Faide d'un outil specia- 
lise. Ici, cette operation sera realisee manuellement car la syntaxe des deux langages est tres proche 
et il est tres simple de passer de Fun a F autre et vice versa. 

Avant de proceder au portage du code de la classe de service, il est possible de verifier que Fimple- 
mentation de service minimale generee fonctionne correctement. Pour cela, il faut simplement : 

1. supprimer les trois classes generees par defaut (Ai rAvai 1 ability. cs, CarAvai 1 abi 1 ity.es et Hotel - 
Avai 1 abi 1 i ty . cs) car celles-ci ont deja ete recuperees et renommees a partir de Fapplication Web 
Java ; 

2. transformer la classe abstraite generee par defaut, en classe concrete ; 

3. transformer les methodes abstraites generees par defaut, en methodes concretes et les modifier de 
maniere a renvoyer un resultat par defaut. 

Vous pouvez telecharger le resultat de cette transformation sur www.editions-eyrolles.com. 

Validation du service de reservation genere 

Pour tester cet embryon de service, a partir de Visual Studio.NET, il est possible d'utiliser le menu 
Debug>Start wi thout Debuggi ng, ce qui provoque la generation d'un client Web de test par introspection 
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de la classe du service et invocation du service a Fadresse http://localhost/reservation_service_sw-voyages/ 
ReservationService.asmx, comme le montre la figure 25-2 : 
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Figure 25-2 

Client de test Web genere par Visual Studio.NET. 

A partir de ce client de test, il est possible de tester isolement chaque methode exposee et de verifier 
ainsi que la generation du service s'est bien passee. 

II est possible de realiser une verification plus poussee en utilisant la partie cliente de F application 
deja precedemment transformee en application Web ASP.NET. 

Au prealable, il est necessaire de modifier le point d'acces du service dans la description WSDL du 
service de reservation, e'est-a-dire le fichier {XINET_HOME£}\reservation_sw-voyages\services\ 
ReservationService.wsdl, en remplacant Fadresse du service Java : 

k<soap: address location= 
" http://www.sw- voyages. com :8080/reservation_sw-voyages/servlet/rpcrouter"> 

par celle du nouveau service C# : 

I<soap:address location= 
"http://www.sw-voyages.com/reservation_service_sw- 
voyages/ReservationService.asmx"/> 
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Apres avoir opere cette modification, il suffit d'ouvrir un navigateur et de le faire pointer sur Fadresse 

http://www.sw-voyages.com/reservation_sw-voyages/index.html. 

Apres saisie des caracteristiques du voyage et demande de reservation, Fecran de 1' application doit 
refleter une absence de disponibilites, comme le montre la figure 25-3 : 
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Figure 25-3 

Verification du service genere a partir de V application Web ASP.NET. 



Des lors, nous sommes assures de la continuite entre la partie cliente de 1' application Web .NET et la 
partie serveur dont une partie a ete portee a partir de F implementation Java et dont un noyau de 
service Web a ete genere a partir de la description de service en format WSDL. II ne reste plus ici 
qu'a finaliser ce noyau de service Web en le completant par le portage de F implementation Java. 

Generation des proxy-services de reservation 

Afin de rendre F architecture de F implementation C# plus souple, nous allons generer des proxy- 
services de reservation specifiques a chacun des partenaires. L'outil wsdl .exe du framework .NET 
permet egalement de generer le proxy-service equivalent a partir de la description WSDL du service 
de reservation du partenaire. 
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Proxy-service de reservation automobile 

Voici la demarche a suivre pour generer le proxy-service de reservation automobile : 

1. Demarrez le serveur Tomcat pour utiliser la partie serveur de l'application Web Java. 

2. Modifiez le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-automobilisme-xml\services- 
type\ReservationServi ce-i nterf ace. wsdl pour attribuer des valeurs aux attributs soapAction des 
balises operation, telles que : 

<soap: operation soapAction="urn:ReservationService/cancel"/> 

<soap: operation soapAction="urn:ReservationService/book"/> 

<soap: operation soapAction="urn:ReservationService/getCarAvailabilities"/> 

<soap: operation soapAction="urn:ReservationService/search"/> 

3. Generez le contenu du fichier ReservationServiceCarProxy.es, via une fenetre d'invite de 
commandes, par la commande : 

wsdl 

/out:C:\Inetpub\wwwroot\reservation_service_sw-voyages\ReservationServi 

ceCarProxy.es 

/namespace: com. swvoyages. reservation 

http://www.sw-voitures . com: 8080/ reservation_sw- voitures /services/ ReservationService. wsdl 

Vous pouvez telecharger le fichier ainsi genere sur www.editions-eyrolles.com. 



Referencement dynamique du service Web cible 

La classe generee reference ici, a travers I'affectation de la variable Url par le constructeur de la classe, I'adresse 
http://www.sw-voitures.com:8080/reservation_sw-voitures/servlet/rpcrouter trouvee par I'analyseur syntaxique 
dans la specification de service WSDL utilisee en parametre de la commande wsdl .exe. Bien entendu, cette 
variable peut etre modifiee dynamiquement pour permettre I'acces aux implementations d'autres partenaires qui 
respectent la formalisation du service abstrait reference par I'espace de noms de la classe (e'est-a-dire http: // 
www.sw-automobil isme-xml .org: 8080/ reservation_sw-automobil isme-xml /services-type/Reser- 
vati onServi ce-i nterf ace). C'est cette possibility qui ouvre la voie a I'ouverture du systeme de reservation de 
SW-Voyages a de nouveaux partenaires. 



Proxy-service de reservation aerienne 

Voici la demarche a suivre pour generer le proxy-service de reservation aerienne : 

1. Demarrez le serveur Tomcat pour utiliser la partie serveur de l'application Web Java. 

2. Modifiez le fichier {%TOMCAT_HOME%}\webapps\reservation_sw-aviation-xml\services-type\ 
ReservationServi ce-i nterf ace. wsdl pour attribuer des valeurs aux attributs soapAction des balises 
operation, telles que : 



<soap: operation soapAction="urn:ReservationService/cancel"/> 
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<soap: operation soapAction="urn:ReservationService/book"/> 

<soap: operation soapAction="urn:ReservationService/getAirAvailabilities"/> 

<soap: operation soapAction="urn:ReservationService/search"/> 

3. Generez le contenu du fichier ReservationServiceAirProxy.es, via une fenetre d'invite de 
commandes, par la commande : 

wsdl 

/out:C:\Inetpub\wwwroot\reservation_service_sw-voyages\ReservationServi 

ceAirProxy.es 

/namespace: com. swvoy ages. reservation 

http://www.sw-ai r. com: 8080/ reservation_sw-ai r/services/ReservationService.wsdl 

Le fichier issu de cette generation n'est pas presente ici, car il presente tres peu de differences avec 
celui decrit dans le cadre de la generation du proxy-service de reservation automobile : seuls l'URI 
du schema et l'URL du point d'acces au service changent, et le code genere correspondant a la 
methode getAi rAvai 1 abi 1 i ties remplace le code equivalent genere pour la methode getCarAvai 1 a- 
bi 1 i ties. 

Proxy-service de reservation hoteliere 

Voici la demarche a suivre pour la generer le proxy-service de reservation hoteliere : 

1. Demarrez le serveur Tomcat pour utiliser la partie serveur de 1' application Web Java. 

2. Modifiez le fichier {$TOMCAT_HOME%}\webapps\reservation_sw-hotellerie-xml\services-type\ 
ReservationService-interface.wsdl pour attribuer des valeurs aux attributs soapAction des bali- 
ses operation, telles que : 

<soap: operation soapAction="urn:ReservationService/cancel"/> 

<soap: operation soapAction="urn:ReservationService/book"/> 

<soap: operation soapAction= "urn :ReservationService/getHotel Avail abi 1 ities"/> 

<soap: operation soapAction="urn:ReservationService/search"/> 

3. Generez le contenu du fichier ReservationServiceHotelProxy.es, via une fenetre d'invite de 
commandes, par la commande : 

wsdl 

/out:C:\Inetpub\wwwroot\reservation_service_sw-voyages\ReservationServi 

ceHotel Proxy.cs 

/namespace: com. swvoy ages. reservation 

http :/ /www. sw- hotels. com: 8080/ reservation_sw-hotels/services/ReservationService. wsdl 
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Le fichier issu de cette generation n'est pas non plus presente ici car il presente tres peu de differen- 
ces avec celui decrit dans le cadre de la generation du proxy-service de reservation automobile : seuls 
l'URI du schema et FURL du point d'acces au service changent, et le code genere correspondant a la 
methode getHotel Avai 1 abi 1 1 11 es remplace le code equivalent genere pour la methode getCarAvai 1 a- 
bil ities. 

Resultat du portage dans le squelette du service de reservation 

Le code presente ci-apres constitue le resultat du portage de 1' implementation Java du service Web de 
reservation de SW- Voyages sur la base du squelette de service C# genere precedemment. Cette 
implementation de troisieme generation exploite les trois proxy-services (aerien, automobile et hote- 
lier) que nous venons de generer (voir code complet a telecharger sur www.editions-eyrolles.com). 

La definition de laclasse ReservationService.asmx.es se presente ainsi : 

[WebServiceBindingAttribute(Name="ReservationService" , 
Namespace="http://www.sw-tourisme-xml .org:8080/reservation_sw-tourisme- 
xml/services-type/ReservationService- interface" )] 

[Soaplncl udeAttribute(typeof (Hotel Availability))] 

[Soaplncl udeAttribute(typeof (CarAvailabil ity) )] 

[Soaplncl udeAttribute(typeof (AirAvailabil ity) )] 

public class ReservationService : WebService, IReservationService { 

} 

Le constructeur de la classe realise 1' acquisition des trois instances de proxy-services de reservation 
et des URL des points d'acces correspondants, via Fannuaire UDDI : 

public ReservationService( ) { 
if (finder==null ) { 
String[] parameters = this . Finder. lookup( 

UDDI_INQUIRE_URL, AI R_TMODEL_NAME) ; 
this.AirProxy.Url = parameters [1]; 
parameters = this. Finder. lookup( 

UDDI_INQUIRE_URL, CAR_TMODEL_NAME) ; 
this.CarProxy.Url = parameters [1]; 
parameters = this. Finder. lookup( 

UDDI_INQUIRE_URL, HOTEL_TMODEL_NAME) ; 
this.HotelProxy.Url = parameters [1]; 
} 
} 

La methode cancel invoque successivement les trois proxy-services afin d'obtenir la reponse des 
partenaires. La definition de la methode se presente de la maniere suivante : 

[WebMethodAttributeO] 
[SoapRpcMethodAttribute("urn:ReservationService/cancel " , 

Request Names pace=" urn: ReservationService" , 

ResponseNamespace="urn: ReservationService")] 
[return: SoapElementAttribute( "return" )] 
public bool cancel (int argO) { 
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La methode book invoque successivement les trois proxy-services afin d'obtenir la reponse des parte- 
naires. Void sa definition : 

[WebMethodAttributeO] 
[SoapRpcMethodAttribute("urn:ReservationService/book" , 

RequestNamespace="urn:ReservationService" , 

ResponseNamespace="urn:ReservationService")] 
[return: SoapElementAttribute( "return" )] 

public bool bookdnt argO, int argl, int arg2, int arg3, int arg4) { 
} 

La methode getAirAvai labilities invoque le proxy-service du partenaire de reservation aerienne 
afin d'obtenir ses disponibilites. Sa definition est la suivante : 

[WebMethodAttributeO] 

[Soa pRpcMet hodAttributet "urn :ReservationService/getAirAvai labilities" , 

Request Namespace="urn:ReservationService" , 

ResponseNamespace="urn:ReservationService")] 
[return: SoapElementAttributet "return" )] 
public AirAvailability[] getAirAvailabilitiesdnt argO) { 
1 

La methode getCarAvai 1 abi 1 1 ti es invoque le proxy-service du partenaire de reservation automobile 
afin d'obtenir ses disponibilites. Voici sa definition : 

[WebMethodAttributeO] 

[Soa pRpcMet hodAttribute( "urn :ReservationService/getCarAvai labilities" , 

RequestNamespace="urn:ReservationService" , 

ResponseNamespace="urn:ReservationService")] 
[return: SoapElement Attribute ("ret urn" )] 
public CarAvailability[] getCarAvailabilitiesdnt argO) { 
} 

La methode getHotel Avai 1 abi 1 i ti es invoque le proxy-service du partenaire de reservation hoteliere 
afin d'obtenir ses disponibilites : 

[WebMethodAttributeO] 

[Soa pRpcMethodAttributet "urn :ReservationService/getHotel Avai labilities" , 

RequestNamespace="urn:ReservationService" , 

ResponseNamespace="urn:ReservationService")] 
[return: Soap El ement Attribute ("return" )] 

public Hotel Availabil ity[] getHotelAvailabilitiesdnt argO) { 
} 

La methode search invoque successivement les trois proxy-services afin d'obtenir la reponse des 
partenaires : 

[WebMethodAttributeO] 

[Soa pRpcMethodAttributet "urn :ReservationService/search" , 

Request Namespace="urn:ReservationService" , 

ResponseNamespace="urn:ReservationService")] 
[return: SoapElementAttributet "return")] 
public int searchdnt argO, String argl, String arg2, bool arg3, int arg4. 
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int arg5, int arg6, int arg7, int arg8, int arg9, bool arglO, bool argil) 



Compacite du code et utilisation de proxy-services 

[.'implementation en langage C# est plus compacte que celle que nous avons realisee precedemment en Java. 
Cela tient au fait que, pour la version .NET, nous n'avons pas eu besoin de recuperer les espaces de noms asso- 
cies aux schemas des types de donnees a serialiser/deserialiser, c'est-a-dire les types Air-Availability, 
CarAvai 1 abi 1 i ty et Hotel Avai 1 abi 1 1 ty et les tableaux correspondants. Ces informations etaient necessaires 
au bon fonctionnement de I'implementation Apache SOAP mais ne le sont pas pour ('implementation .NET. Cela 
nous a epargne I'utilisation de I'equivalent .NET de la librairie WSDL4J d'IBM. 

Une autre raison explique la taille plus compacte de la classe C# : I'utilisation des proxy-services generes a permis 
de rendre le code de cette classe plus clair et moins prolixe (au prix cependant de la generation de trois classes 
supplementaires). Cela n'est bien entendu pas une exclusivite du framework .NET et la grande majorite des envi- 
ronnements Java proposent cette fonctionnalite. 



Resultat du portage des classes de support Java en C# 

Les classes de servitude Java sont portees en langage C# par equivalence stricte. La plupart de ces 
classes implementent des interfaces C# qui ne sont pas reproduites ici. 

Le registre local des reservations (fichier ReservationManager.es) etend egalement la classe Hashta- 
bl e . cs du framework .NET (telechargez le code source sur www.editions-eyrolles.com). 

De meme, la reservation (fichier Reservation.es) presente peu de differences avec la version Java 
(telechargez le code source sur www.editions-eyrolles.com). 

Des classes de disponibilites, seule la classe AirAvailability.es est reproduite ici (telechargez le 
code source sur www.editions-eyrolles.com) : comme pour les versions Java, les classes CarAvai 1 a- 
bi 1 i ty . cs et Hotel Avai 1 abi 1 i ty . cs sont construites sur le meme modele et leur presentation n'appor- 
terait pas d' elements nouveaux, necessaires a une bonne comprehension du scenario. 

On peut remarquer que la directive SoapTypeAttribute appliquee a la classe contient une partie des 
informations enregistrees dans le descripteur de deploiement du service Web Java : 

I[SoapTypeAttribute( "AirAvai lability" , 
" http://www.sw-a vi ation-xml .org:8080/reservation_sw-aviation- 
xml/schemas/ReservationService- schema")] 

Si Ton prend en compte cette directive et celles qui s'appliquent a la classe du service Web Reserva- 
tionService.asmx.es (directive WebServiceBindingAttribute et directive SoapIncludeAttribute), on 
dispose de l'ensemble des informations utilisees pour le deploiement Java, a l'exception de la classe 
de serialisation/deserialisation par defaut qui n'est pas declaree explicitement en C#. 

La derniere classe utilisee par l'ensemble des classes de servitude C# est la classe d' exception gene- 
rique (ReservationException.es). 

Celle-ci etend la classe Appl i cati onExcepti on . cs du framework .NET (telechargez le code source sur 
www.editions-eyrolles.com). 
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La classe de recherche des URL des points d'acces aux implementations des partenaires de SW- 
Voyages (fichier ReservationFinder.es) implemente une politique de recherche des partenaires iden- 
tique a celle qui a ete utilisee dans la version Java. 

Cette classe fait egalement appel a Fannuaire UDDI du serveur Glue (Java). LAPI d'acces a 
l'annuaire est bien entendu differente. Celle qui est utilisee ici est celle de Microsoft : il s'agit de 
celle du SDK UDDI version 1.76 beta. 

Pour pouvoir utiliser la librairie UDDI dans Fenvironnement Visual Studio.NET, il faut tout d'abord 
se positionner dans Fexplorateur de solution, selectionner le sous -repertoire References du projet 
reservation_service_sw-voyages dans la solution SW-Voyages Reservation et demander Fajout de 
references par le menu contextuel Add Reference.... Dans Fonglet .NET, il faut alors selectionner le 
composant « Microsoft. UDDI. SDK » (version 1.76.2121.1) par le bouton Select, puis Fajouter par 
le bouton OK. 

La classe ReservationFinder.es est la seule classe qui necessite Futilisation de FAPI UDDI (tele- 
chargez le code source sur www.editions-eyrolles.com). 

On peut noter ici la remarquable similitude entre les implementations Java Glue et C# Mcrosoft de 
FAPI UDDI. 

Applications Web des partenaires de SW-Voyages 

Par rapport au deuxieme scenario, les applications Web Java deployees dans le cadre de ce troisieme 
scenario par les partenaires sont inchangees. Le passage a la technologie Microsoft .NET, opere par 
SW-Voyages, ne necessite aucune adaptation, ni aucun redeploiement de la pail de ses partenaires. 

Le developpement de la troisieme generation du service Web de reservation de SW-Voyages n' a done 
eu aucun impact sur les systemes d'information de ses partenaires. 

Partie serveur de V application Web des partenaires de SW-Voyages 

II n'y a aucun changement par rapport au deuxieme scenario (voir ci-dessus). 
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Architecture 
en processus metier (BPEL) 



Ce chapitre presente une architecture de service statique dans laquelle F implementation du service 
de reservation de SW- Voyages est structuree sous forme de processus metier. Cette architecture 
exploite une implementation des specifications BPEL, WS -Coordination et WS -Transaction. Elle 
s'appuie sur F usage du produit BPEL Orchestration Server de la societe Collaxa. 

Cette quatrieme generation du logiciel de reservation correspond au scenario d' architecture n°4 
presente chapitre 22. 

L implementation du service Web de SW- Voyages fait appel a la technologie Java utilisee par le 
produit de Collaxa. 

Implementation 

Afin de pouvoir beneficier des fonctionnalites transactionnelles du produit, il est imperatif que les 
services de reservation des quatre partenaires reposent sur une implementation des trois specifica- 
tions concernees. Cela implique la reecriture du service de SW- Voyages, mais egalement celle des 
services de ses trois partenaires. 

Du fait de la publication encore tres recente de ces specifications, il n'existe pas encore d' implemen- 
tations operationnelles. Le serveur de Collaxa est Fune des toutes premieres disponibles dans ce 
domaine. 

Afin de simplifier la mise en ceuvre du scenario d' architecture, le deploiement des composants appli- 
catifs de chacun des partenaires est realise dans une seule instance du serveur Collaxa, dans un 
format identique a celui des exemples presentes par le produit. 
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Produits utilises 

Du cote client (gestion du poste de travail), nous reprenons les produits mis en ceuvre chapitre 23 
(« Architecture statique - Implementation des services Java »), c'est-a-dire le serveur Apache 
Tomcat 4.1.12 associe au SDK Standard Edition 1.4.1 de Sun Microsystems, et le behavior WebSer- 
vice 1.0.1.1120 de Microsoft. Le parametrage effectue sur ces produits, notamment en ce qui 
concerne les noms de domaines, ne change pas dans le scenario d' architecture n°4. 

En revanche, pour ce qui touche aux serveurs applicatifs, les produits utilises dans les scenarios 
d' architecture n os l, 2 et 3 ne sont plus utilises et sont remplaces par le seul serveur de Collaxa. 

Apache Tomcat 4. 1. 12 

Voir chapitre 23. 

Collaxa BPEL Orchestration Server 2.0 beta 4 

Nous allons done utiliser ici le produit BPEL Orchestration Server de la societe Collaxa. Ce produit, 
actuellement disponible en version 2.0, en phase beta 4, existe en plusieurs versions : Collaxa for 
BEA WebLogic (6. 1 et 7.0) et standalone (serveurs HTTP Jetty et EJB JBoss). D'autres versions sont 
prevues : Collaxa for Sun ONE (7.0) et Collaxa for WebSphere. Pour cette implementation, nous 
utiliserons la version standalone. 

Le produit BPEL Orchestration Server peut etre telecharge en version d' evaluation a partir de 
l'adresse http://www.collaxa.com/product.download.html. 

Le repertoire d' installation C:\Collaxa_2.0 (repertoire modifie propose a F installation) du moteur 
d' execution de scenarios BPEL Orchestration Server sera represente par la variable {$C0LLAXA_H0ME%}. 



Problemes de stabilite 

Les scenarios BPEL utilises dans ce chapitre fonctionnent bien lorsqu'ils sont invoques directement a I'interieur de 
la console du serveur. En revanche, sauf si on ne demande qu'une reservation aerienne, ceux-ci ont beaucoup de 
mal a fonctionner lorsqu'ils sont invoques a partir du navigateur Internet et de la partie cliente de I'application Web. 
Souvent, I'execution des scenarios se termine par la levee d'une exception qui empeche le service de se terminer 
normalement et provoque le declenchement des methodes d'annulation ou de compensation des transactions (voir 
plus loin ces notions). Ces problemes semblent dus a la perte aleatoire distances d'objets entre les differentes 
invocations des scenarios (perte des reservations enregistrees dans le singleton ReservationManager ou perte 
de donnees dans les reservations). Ces anomalies n'affectent le serveur que dans une configuration particuliere 
(client implements dans un navigateur et interrogation du serveur par polling) et seront tres certainement corrigees 
dans les prochaines versions du serveur. 



Afin d'avoir une vue d'ensemble de ce produit, nous invitons le lecteur a consulter trois documents 
de presentation du serveur de Collaxa : 

• une description generate du produit (Product Tour) accessible a partir de la page http:// 
www. collaxa. com/product, welcome, html ; 

• la prise en main rapide (Quick Start) telechargeable a http://www.collaxa.com/pdf/collaxa-bpel101.pdf ; 
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• le guide developpeur dont la derniere version peut etre consultee a l'adresse http://www.collaxa.com/ 
developer, download. dev20latest. html.pxml. 

Ce tour d'horizon est tres interessant dans la mesure ou nous n'utilisons, dans ce scenario d' architec- 
ture n°4, qu'une faible partie des fonctionnalites du serveur de Collaxa. Un certain nombre de ces 
possibilites sont d'ailleurs illustrees via l'utilisation d'une console en ligne, similaire a celle utilisee 
plus loin dans ce chapitre, accessible a l'adresse http://bpel.collaxa.com/BPELConsole. 

Microsoft behavior WebService 1.0.1.1120 

Voir chapitre 23. 

Sun Microsystems SDK Standard Edition 1.4. 1 

Voir chapitre 23. 

Parametrage du serveur Collaxa 

Apres installation du produit, aucun parametrage particulier n'est necessaire. 

Les applications Web des quatre partenaires seront deployees comme les exemples de Collaxa, dans 
le repertoire {SSC0LLAXA_H0ME3S}\cxdk\samples : 

• sous-repertoire reservation_sw-voyages pour SW- Voyages ; 

• sous-repertoire reservatiori_sw-ai r pour SW-Air ; 

• sous-repertoire reservation_sw-hotels pour SW-Hotels ; 

• sous-repertoire reservation_sw-voitures pour SW-Voitures. 

Une petite adaptation doit cependant etre effectuee dans le fichier {XCOLLAXA_HOMEX}\server- 
defaulUdefault.xml. II faut en effet remplacer FURL du parametre soap-router-endpoint-url : 

<property name=" soap-router-endpoint-url ">http://mymachine:9700</property> 

par la valeur : 

<property name=" soap-router-endpoint-url ">http:/ /www. sw- voyages. com :9700</property> 

Cette modification permet d' aligner le domaine de la partie cliente avec celui du serveur de SW- 
Voyages. La presence de ce parametre ne permet pas d'utiliser les trois autres domaines sur un seul 
serveur Collaxa comme cela a ete realise dans les trois chapitres precedents avec le serveur Apache 
Tomcat. Nous nous contenterons done, afin de minimiser la complexite de cette configuration, de 
faire cohabiter les applications des quatre partenaires dans un seul et unique serveur associe au 
domaine de SW- Voyages. 
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Developpement 

La cinematique des echanges entre les serveurs, decrite chapitre 22 (voir la section « Scenario n°l »), 
dans le cadre d'une architecture statique (pas d' utilisation d'annuaire UDDI), est identique a celle 
mise en ceuvre dans ce scenario d' architecture n°4. 

Le moteur d' execution de Collaxa utilise deux syntaxes pour la redaction des scenarios BPEL : la 
syntaxe pure et une syntaxe hybride, avec un style qui utilise une metaphore similaire aux JavaServer 
Pages (JBPEL). Les scenarios JBPEL sont rediges sous la forme de classes Java annotees qui sont 
ensuite compilees (par un compilateur de scenarios) dans un format Java standard cible. Nous avons 
choisi cette approche car elle permet au developpeur de rester dans Fenvironnement Java pour la 
redaction et la mise en ceuvre des scenarios. 

Ces classes Java etendent la classe abstraite BPELScenario.java qui n'expose qu'une seule methode 
publique process, sans contraintes sur le type du(des) parametre(s) de la methode, ni sur le type de 
retour. Le compilateur de scenarios n'autorise pas la presence de plusieurs methodes process de 
signatures differentes. Cette methode publique est automatiquement exposee en tant qu'operation (au 
sens WSDL) d'un service Web et peut done etre invoquee via le protocole SOAP. Par ce moyen, il est 
done possible de declencher a distance l'activation d'un scenario BPEL deploye sur un serveur 
Collaxa. Cette contrainte d' interface nous oblige a reprendre la conception du service SW- Voyages 
des scenarios d' architecture n os l et 2 qui repose sur la classe ReservationService. Java. En pratique, 
il est assez naturel d'« eclater » la classe initiale en autant de scenarios BPEL que de methodes expo- 
sees dans l'interface : ainsi la classe ReservationService. Java de SW- Voyages disparait au profit de 
six scenarios BPEL (qui mettent en oeuvre les operations search, book, cancel, getAirAvailabil i- 
ties, getCarAvailabilities et getHotel Avail abil ities) et chacune des classes des partenaires est 
remplacee par quatre scenarios BPEL (search, book, cancel et getAirAvailabil ities, ou getCar- 
Availabilities ou encore getHotel Avail abil ities selon le partenaire). 

Orchestration du processus de reservation 

Cette nouvelle structuration des services Web des quatre partenaires se decline done, du point de vue 
de F application cliente en F invocation des six scenarios BPEL de SW- Voyages : 

1 . recherche de disponibilites ; 

2. recuperation des disponibilites aeriennes ; 

3. recuperation (optionnelle) des disponibilites hotelieres ; 

4. recuperation (optionnelle) des disponibilites automobiles ; 

5. annulation de recherche de disponibilites ; 

6. reservation de disponibilites. 

Le principe d' execution des scenarios BPEL par le moteur Collaxa que nous avons choisi est asyn- 
chrone (F execution synchrone des scenarios BPEL est aussi possible). La requete d'invocation asyn- 
chrone d'un scenario BPEL (soapAction i ni ti ate) obtient en reponse un message d' accuse de recep- 
tion. Ensuite, pour connaitre F issue et les resultats de F execution du scenario invoque, deux 
mecanismes sont disponibles : 
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• Polling : l'application cliente emet periodiquement des interrogations sur Petat de l'execution du 
scenario et le serveur Collaxa repond soit avec un message d'attente (« execution en cours »), soit 
avec le resultat du traitement reussi, soit encore avec un message d'erreur. Ce mecanisme est 
destine a l'usage des applications clientes qui n'ont qu'une capacite de client SOAP (la capacite a 
emettre des requetes SOAP et a recevoir des reponses SOAP, emboitees respectivement dans des 
requete et des reponses HTTP). Le client de notre etude de cas, qui s'execute dans le navigateur 
Internet Explorer, appartient a cette categorie d' applications. 

• Callback : le serveur Collaxa emet, a la fin de l'execution reussie du scenario BPEL, ou lors de la 
levee d'une exception qui interrompt l'execution, un message SOAP (dans une requete HTTP) a 
l'intention de l'application qui a invoque l'execution du scenario BPEL. Ce mecanisme est viable 
pour des applications « clientes » qui ont une capacite de serveur SOAP (la capacite a recevoir des 
requetes SOAP et a emettre des reponses SOAP) en plus de la capacite client, et qui doivent etre 
cogues et implementees pour pouvoir recevoir et traiter des messages de type callback. Le meca- 
nisme de callback est utilise de facon transparente pour le developpeur dans F interaction entre 
deux applications (eventuellement deux serveurs) Collaxa, lorsque, par exemple, l'execution d'un 
scenario BPEL comporte l'invocation d'un autre scenario « subordonne » mis en ceuvre par une 
autre application Collaxa. Dans ce cas, nous avons vu que le scenario appelant se met en attente de 
callback de la part du scenario appele par une operation explicite (soapAction recei veResul t). Ce 
mecanisme est utilise dans la communication entre SW- Voyages et ses partenaires. 

Les deux mecanismes de polling et callback necessitent que l'invocation d'un scenario BPEL soit 
dotee d'un identifiant qui doit etre rappele ensuite dans les appels de polling et de callback. Le 
moteur Collaxa couple l'execution asynchrone des scenarios avec : 

• la gestion de la fiabilite de Fechange des messages centree sur l'utilisation de files d'attente JMS 
sous-jacentes ; 

• la gestion des activites et des transactions en conformite a la specification WS-Transaction. 

II est interessant de noter que le fonctionnement globalement asynchrone de F architecture d'agrega- 
tion de services peut etre masque completement a Futilisateur final. C'est Foption pour laquelle nous 
avons opte, dans laquelle F interface homme/machine mise en ceuvre via le navigateur donne une 
visibilite pseudo-synchrone de l'execution des services demandes au serveur SW- Voyages (voir la 
mise en ceuvre du client chapitre 22). 

Scenarios de recherche et de recuperation de disponibilites 

La cinematique generate de F orchestration des scenarios de recherche et de recuperation de disponi- 
bilites de reservation se presente telle que Fillustre la figure 26-1. 

L'application cliente invoque tout d'abord le scenario BPEL de recherche de disponibilites de 
SW-Voyages SWVoyages_Reservation_Search (1) via l'emission d'un document xmlSearch- 
Request. Le scenario traite la demande par une invocation en parallele des scenarios de recher- 
che de disponibilites de SW-Air SWAir_Reservation_Search (2), de SW-H6tels (optionnel) 
SWHotels_Reservation_Search (3)etde SW-Voitures (optionnel) SWVoitures_Reservation_Search (4). 
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BCT 



Application cliente 
(requetes asynch rones) 



© 



Orchestration de la recherche de disponibilites 
SW-Voyages (service asynchrone) 



Reception de la requete xmlSearchRequest 
[Taches paralleles] 

[Appel du service de recherche SW-Air] 

Invocation du service 

Attente du resultat (callback) 

[Appel du service de recherche SW-H6tels] 

Invocation du service 

Attente du resultat (callback) 

[Appel du service de recherche SW-Voitures] 

Invocation du service 

Attente du resultat (callback) 
[Fin des taches paralleles] 
Renvoi du resultat (polling) 
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Orchestration de la recuperation des 
disponibilites aeriennes SW-Voyages (service 
asynchrone) 



Reception de la requete 

xmlGetAirAvailabilitiesRequest 

[Appel du service de recuperation SW-Air] 

Invocation du service 

Attente du resultat (callback) 

Renvoi du resultat (polling) 
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Orchestration de la recuperation des 
disponibilites hotelieres SW-Voyages (service 
asynchrone) 



Reception de la requete 

xmlGetHotelAvailabilities Request 

[Appel du service de recuperation SW-H6tels] 

Invocation du service 

Attente du resultat (callback) 

Renvoi du resultat (polling) 



Orchestration de la recuperation des 
disponibilites automobiles SW-Voyages (service 
asynchrone) 



Reception de la requete 

xmlGetCarAvailabilitiesRequest 

[Appel du service de recuperation SW-Voitures] 

Invocation du service 

Attente du resultat (callback) 

Renvoi du resultat (polling) 



SW-Air 



Reception de la requete 
Traitement de la requete 
Rappel (callback) 



SW- Hotels 



Reception de la requete 
Traitement de la requete 
Rappel {callback) 



SW-Voitures 



Reception de la requete 
Traitement de la requete 
Rappel (callback) 



SW-Air 



Reception de la requete 
Traitement de la requete 
Rappel (callback) 



SW- Hotels 



Reception de la requete 
Traitement de la requete 
Rappel (callback) 



SW-Voitures 



Reception de la requete 
Traitement de la requete 
Rappel (callback) 







Recherche de disponibilites 
SW-Air 
(service asynchrone) 
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Recherche de disponibilites 

SW- Hotels 

(service asynchrone) 
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Recherche de disponibilites 

SW-Voitures 

(service asynchrone) 
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Recuperation de disponibilites 
SW-Air 
(service asynchrone) 



IJJJ 

Recuperation de disponibilites 
SW-Hotels 
(service asynchrone) 



Recuperation de disponibilites 

SW-Voitures 

(service asynchrone) 



Figure 26-1 

Cinematique de V orchestration de la recherche et de la recuperation des disponibilites. 



Ces scenarios sont actives en parallele et Fordre de recuperation des disponibilites est indifferent. 
L' execution de ces quatre premiers scenarios se deroule de la facon suivante : si l'un des scenarios ne 
se termine pas correctement, les autres scenarios sont soit annules (canceled) s'ils etaient en cours 
d'execution, soit compenses (compensated) s'ils etaient termines. La charge de codage des taches 
d'annulation et de compensation qui ont un contenu metier incombe au developpeur. Les quatre 
scenarios sont executes dans le cadre d'une activite metier (business activity) WS-Transaction. 

Lorsque 1' application cliente a recupere son numero de recherche de disponibilites, par sollicitation 
intermittente du serveur de SW-Voyages a Faide de l'identifiant de conversation (correlation) attribue 
lors de la requete initiale, celle-ci peut alors immediatement invoquer les scenarios de recuperation 
des disponibilites aeriennes SWVoyages_Reservation_GetAir (5), hotelieres (optionnel) SWVoyages 
_Reservation_GetHotel (7)et automobiles (optionnel) SWVoyages_Reservation_GetCar (9) de SW-Voyages. 
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Ces invocations sont realisees en parallele par F application cliente qui recupere ensuite les resultats 
selon le meme principe que celui adopte pour la recherche (sollicitation intermittente du serveur via 
un identifiant de conversation). Chacun des scenarios de recuperation de disponibilites de SW- Voyages 
invoque a son tour en arriere-plan le scenario correspondant du partenaire : le scenario 
SWAir_Reservation_Get (6) pour SW-Air, SWHotels_Reservation_Get (8) pour SW-H6tels et 
SWVoitures_Reservation_Get (10) pour SW-Voitures. Les scenarios sont executes, deux a deux, dans 
le cadre de business activities WS-Transaction. 

Scenarios d'annulation ou de confirmation de recherche de disponibilites 

La cinematique generate de 1' orchestration des scenarios d'annulation ou de confirmation de recher- 
che de disponibilites de reservation se resume ainsi (figure 26-2) : 







BQ 



Application cliente 
(requetes asynchrones) 
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Orchestration de I'annulation de recherche de 
disponibilites SW-Voyages (service asynchrone) 



Reception de la requete xmlCancel Request 
[laches paralleles] 

[Appel du service d'annulation SW-Air] 

Invocation du service 

Attente du resultat (callback) 

[Appel du service d'annulation SW-H6tels] 

Invocation du service 

Attente du resultat (callback) 

[Appel du service d'annulation SW-Voitures] 
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Figure 26-2 

Cinematique de V orchestration de V annulation ou de la confirmation de recherche de disponibilites. 
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Lorsque l'utilisateur de l'application cliente a effectue ses choix parnii les disponibilites presentees, 
il peut soit demander une confirmation des disponibilites selectionnees (reservation), soit annuler la 
recherche de disponibilites en cours pour eventuellement faire une autre recherche. 

En cas d'annulation, l'application cliente invoque le scenario BPEL d'annulation de recherche de 
disponibilites SWVoyages_Reservation_Cancel (1) de SW- Voyages via remission d'un document 
xml Cancel Request. Le scenario traite la demande par une invocation en parallele des scenarios 
d'annulation de recherche de disponibilites SWAir_Reservation_Cancel (2) de SW-Air, 
SWHotels_Reservation_Cancel (3) de SW-H6tels (optionnel) et SWVoitures_Reservation_Cancel (4) 
de SW-Voitures (optionnel). Comme lors de la recherche de disponibilites, ces scenarios sont actives 
en parallele et l'ordre de recuperation des resultats est indifferent. L' execution de ces quatre scena- 
rios, comme celle des scenarios de recherche de disponibilites, se deroule de la maniere suivante : si 
l'un des scenarios ne se termine pas correctement, les autres scenarios sont soit annules s'ils etaient 
en cours d'execution, soit compenses s'ils etaient termines. La charge de codage des taches d'annu- 
lation et de compensation incombe au developpeur. Les quatre scenarios sont executes dans le cadre 
d'une business activity WS-Transaction. 

Pour la confirmation des disponibilites selectionnees (reservation), l'application cliente invoque le 
scenario BPEL de confirmation de recherche de disponibilites SWVoyages_Reservation_Book (5) de 
SW- Voyages via remission d'un document xmlBookRequest. Le scenario traite la demande par une 
invocation en parallele des scenarios de confirmation de recherche de disponibilites 
SWAir__Reservation_Book (6) de SW-Air, SWHotels_Reservation_Book (7) de SW-H6tels (optionnel) et 
SWVoitures_Reservation_Book (8) de SW-Voitures (optionnel). Comme lors de la recherche et de 
l'annulation de recherche de disponibilites, ces scenarios sont actives en parallele et l'ordre de recu- 
peration des resultats est indifferent. De meme, l'execution de ces quatre scenarios se deroule de la 
facon suivante : si Fun des scenarios ne se termine pas correctement, les autres scenarios sont soit 
annules s'ils etaient en cours d'execution, soit compenses s'ils etaient termines. La charge de codage 
des taches d'annulation et de compensation incombe toujours au developpeur. Les quatre scenarios 
sont executes dans le cadre d'une activite metier WS-Transaction. 



Application Web de SW- Voyages 

Larborescence de l'application Web de la societe SW- Voyages (repertoire reservation_sw-voyages) 
est, bien entendu, differente de celle du scenario d' architecture n°l et se presente maintenant telle 
que l'illustre la figure 26-3. 

Cette arborescence comprend vingt-six fichiers : 

• un fichier build. xml utilise par l'utilitaire cxant.bat, version specifique a Collaxa de l'utilitaire 
Ant de la communaute Apache, pour compiler l'application Web (repertoire {£C0LLAXA_H0ME%}\ 
cxdk\bin) ; 

• six scenarios BPEL en format Java specifique a Collaxa (fichiers d'extension . jbpel) ; 

• six descripteurs de deploiement des scenarios correspondants (fichiers d'extension .xml) ; 

• six schemas de description des documents d'invocation des scenarios de SW- Voyages (fichiers 
d'extension .xsd) ; 
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Figure 26-3 

Arborescence de Vapplication Web de SW- Voyages. 



• trois schemas de description des documents renvoyes par les methodes de recuperation des dispo- 
nibilites (aeriennes, hotelieres et automobiles) de SW- Voyages (fichiers d'extension .xsd) ; 

• quatre classes Java de support aux scenarios de SW- Voyages (fichiers d'extension .Java). 

Dans la suite de ce chapitre, le repertoire qui contient cette arborescence, localise a {£C0LLAXA_H0ME%}\ 
cxdk\samples\reservation_sw- voyages, est designe par la variable {£SW-V0YAGES_H0ME%}. 
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Partie serveur de I 'application Web de SW-Voyages 

La partie serveur de F application Web de SW-Voyages est entierement realisee en technologie Java 
utilisee par le serveur BPEL Orchestration Server de Collaxa. Comme nous l'avons vu, 1' architecture 
du produit necessite une « decomposition » de la classe ReservationService. Java du chapitre 23 en 
six scenarios BPEL : 

ReservationService_Search.jbpel : coordination d'une demande de recherche de disponibilites 
entre SW-Voyages et ses partenaires ; 

ReservationService_GetAir. jbpel : coordination de la recuperation de disponibilites aeriennes 
entre SW-Voyages et son partenaire SW-Air ; 

ReservationService_GetHote1 . jbpel : coordination de la recuperation de disponibilites hotelieres 
entre SW-Voyages et son partenaire SW-H6tels ; 

ReservationService_GetCar. jbpel : coordination de la recuperation de disponibilites automobiles 
entre SW-Voyages et son partenaire SW-Voitures ; 

ReservationService_Book. jbpel : coordination de la confirmation d'une demande de reservation 
de disponibilites entre SW-Voyages et ses partenaires ; 

Res e r v a 1 1 on Se r v 1 ce_Can eel . jbpel: coordination de F annulation d' une demande de reservation de 
disponibilites entre SW-Voyages et ses partenaires. 

Schemas XML des requetes d' invocation 

Chaque scenario est active via F emission d'un message SOAP qui transporte un document contenant 
les parametres necessaires a F execution du scenario. Le code qui suit est un exemple de message qui 
inclut un document xmlSearchRequest destine a invoquer le scenario Reservation- 
Service_Search. jbpel : 

<?xml version='1.0' encoding='utf-8'?> 
<SOAP-ENV:Envelope ...> 
<SOAP-ENV:Body> 
<i ni ti ate xmlns=" http://swvoyages.samples.cxdn.com"> 
<xmlSearchRequest> 
<passengers>K/passengers> 
<from>ParisCDG</from> 
<to>Vienne</to> 
<roundTrip>K/roundTrip> 
<departureDay>13</departureDay> 
<departureMonth>3</departureMonth> 
<departureYear>2003</departureYear> 
<arrival Day>13</arrival Day> 
<arrivalMonth>3</arrivalMonth> 
<arrivalYear>2003</arrivalYear> 
<hotel Requested>true</hotel Requested> 
<carRequested>false</carRequested> 
</xm!SearchRequest> 
</initiate> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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Ce message est emboite dans une requete HTTP dont la reponse contient comme entree de l'en-tete 
SOAP l'identifiant de la conversation qu'il faut rappeler lors du polling de recuperation du resultat de 
la requete. 

Voici les schemas XML des documents qui transported les requetes asynchrones a destination du 
serveur de SW- Voyages. 

Schema XML de la requete search 

La requete de demande de recherche de disponibilites est ainsi redigee (fichier {%SW-V0YAGES_H0ME$} \ 
Search. xsd) : 

<?xml version="1.0"?> 

<schema t a rgetNamespace=" http://swvoyages.samp! es.cxdn.com" 
xmlns:tns=" http://swvoyages.samples.cxdn. com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="SearchRequest"> 
<complexType> 
<all> 
<element name="passengers" type="int"/> 
<element name="from" type="string"/> 
<element name="to" type="string"/> 
<element name="roundTrip" type="boolean"/> 
<element name="departureDay" type="int"/> 
<element name="departureMonth" type="int"/> 
<element name="departureYear" type="int"/> 
<element name="arri valDay" type="int"/> 
<element name="arri valMonth" type="int"/> 
<element name="arrivalYear" type="int"/> 
<element name="hotel Requested" type="boolean"/> 
<element name="carRequested" type="boolean"/> 
</all> 
</complexType> 
</element> 

<element name=" Search Fa ilure"> 
<complexType> 
<element name="searchRequest" type="tns:SearchRequest" /> 
<element name="message" type="string" /> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete getAirAvailabilities 

La requete de demande de recuperation de disponibilites aeriennes se decrit ainsi (fichier 

{SSW-VOYAGES_HOME%}\GetAir.xsd) : 

<?xml version="1.0"?> 

<schema t a rgetNamespace=" http://swvoyages.samp! es.cxdn.com" 

xmlns:tns=" http://swvoyages.samples.cxdn. com" 

xmlns=" http://www.w3.org/2001/XMLSchema"> 

<element name="GetAirAvail abil itiesRequest"> 
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<complexType> 
<all> 

<element name="reservationId" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="GetAi rAvailabil itiesFailure"> 
<complexType> 
<all> 
<el ement name="getAirAvailabilitiesRequest" 
type="tns:GetAi rAvailabil i ties Request" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete getHotelAvailabilities 

La requete de demande de recuperation de disponibilites hotelieres s'exprime de la maniere suivante 
(flchier {SSSW-V0YAGES_H0ME3;}\GetHotel .xsd) : 

<?xml version="1.0"?> 

<schema target Namespace="http://swvoy ages. samples. cxdn.com" 
xmlns:tns=" http://swvoyages.samp! es.cxdn.com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<el ement name="GetHotel Avail abil itiesRequest "> 
<complexType> 
<all> 

<element name="reservationId" type="int"/> 
</all> 
</complexType> 
</element> 

<el ement name="GetHotel Avail abilities Fail ure"> 
<complexType> 
<all> 
<el ement name= "get Hotel Avail abil itiesRequest" 
type="tns:GetHotel Avail abil itiesRequest" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete getCarAvailabilities 

La requete de demande de recuperation de disponibilites automobiles se presente ainsi (fichier 

{%SW-VOYAGF_S_HOME£}\GetCar.xsd) : 

|<?xml version="1.0"?> 
<schema target Namespace="http: //swvoy ages. samples .cxdn.com" 
xmlns:tns=" http://swvoyages.samp! es.cxdn.com" 
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xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="GetCarAvail abil itiesRequest"> 
<complexType> 
<all> 

<element name="reservationId" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="GetCarAvail abil i ties Fail ure"> 
<complexType> 
<all> 
<element name="getCarAvailabil i ties Request" 
type="tns:GetCar Avail abil itiesRequest" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete book 

La requete de demande de reservation s'exprime de la maniere suivante (flchier {£SW-V0YAGES_H0ME%}\ 
Book.xsd) : 

<?xml version="1.0"?> 

<schema t a rgetNamespace=" http://swvoyages.samp! es.cxdn.com" 
xmlns:tns=" http://swvoyages.samples.cxdn. com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="BookRequest"> 
<complexType> 
<all> 
<element name="reservationId" type="int"/> 
<element name="departureChoice" type="int"/> 
<element name="arrivalChoice" type="int"/> 
<element name="hotelChoice" type="int"/> 
<element name="carChoice" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="BookFail ure"> 
<complexType> 
<all> 
<element name="bookRequest" type="tns:BookRequest" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 
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Schema XML de la requete cancel 

La requete d'annulation de recherche de disponibilites est la suivante (fichier {%SW-VOYAGES_HOMEft}\ 
Cancel .xsd) : 

<?xml version="1.0"?> 

<schema targetNamespace="http://swvoy ages. samples .cxdn.com" 
xmlns:tns=" http://swvoyages.samp! es.cxdn.com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="Cancel Request"> 
<complexType> 
<all> 

<element name="reservationId" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="Cancel Fail ure"> 
<complexType> 
<all> 
<element name="cancel Request" type="tns:Cancel Request" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML des disponibilites aeriennes, hotel ieres et automobiles 

Les trois scenarios de recuperation de disponibilites renvoient des structures complexes de donnees. 
Celles-ci sont egalement retournees a F application cliente sous forme de documents : 

• recuperes, sur demande de 1' application cliente aupres du serveur (polling), dans la reponse 
HTTP; 

• expedies, a destination de 1' application cliente par le serveur (callback), dans la requete HTTP. 
Ces disponibilites sont decrites par des schemas XML. 

Schema XML des disponibilites aeriennes 

Les disponibilites aeriennes s'expriment de la maniere suivante (fichier {%SW-V0YAGES_H0ME%}\ 

Ai r Avail abil i ties. xsd) : 

<?xml version="1.0"?> 
<schema 
targetNamespace=" http://swvoyages.samples.cxdn. com" 
xmlns:tns=" http://swvoyages.samp! es.cxdn.com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<complexType name="ArrayOfAi rAvailabil ity"> 
<sequence> 

<element ref="tns:Ai rAvailabil ity" max0ccurs="unbounded'7> 
</sequence> 
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</complexType> 

<complexType name="Ai rAvailabil ity"> 
<all> 

<element name="id" type="int"/> 

<element name="ai rCompany" nillable="true" type="string"/> 

<element name="flightNumber" nil 1 able="true" type="string"/> 

<element name="departureAi rport" nill able="true" type="string"/> 

<element name="arrival Airport" nil lable="true" type="string"/> 

<element name="departureHour" nill able="true" type="string"/> 

<element name="arrivalHour" nil lable="true" type="string"/> 

<element name="di rection" type="boolean"/> 

<element name="price" type="float"/> 

<element name="remoteId" type="int"/> 
</all> 
</complexType> 
</schema> 

Schema XML des disponibilites hotelieres 

Les disponibilites hotelieres se represented de la maniere suivante (fichier {%SW-V0YAGES_H0ME%}\ 
Hotel Avail abil i ties.xsd) : 

<?xml version="1.0"?> 
<schema 
target Namespace=" http://swvoyages.samp! es.cxdn.com" 
xmlns:tns=" http://swvoyages.samples.cxdn. com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<complexType name="ArrayOf Hotel Avail ability "> 
<sequence> 

<element ref="tns: Hotel Avail abil ity" maxOccurs=" unbounded "/> 
</sequence> 
</complexType> 

<complexType name=" Hotel Availability"> 
<all> 
<element name="id" type="int"/> 

<element name="hotel Rental Company" nil lable="true" type="string"/> 
<element name="hotelName" nill abl e="true" type="string"/> 
<element name="hotel Location" nill able="true" type="string"/> 
<element name="higherPrice" type="float"/> 
<element name="lowerPrice" type="float"/> 
<element name="remoteId" type="int"/> 
</all> 
</complexType> 
</schema> 

Schema XML des disponibilites automobiles 

Les disponibilites automobiles sont representees ainsi (fichier {%SW-VOYAGES_HOME%}\CarAvailabi- 

1 i ties.xsd) : 

|<?xml version="1.0"?> 
<schema 
target Namespace=" http://swvoyages.samp! es.cxdn.com" 
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xmlns:tns=" http://swvoyages.samp! es.cxdn.com" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<complexType name="ArrayOfCarAvailabil ity"> 
<sequence> 

<element ref="tns:CarAvailabil ity" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 

<complexType name="CarAvailabil ity"> 
<all> 
<element name="id" type="int"/> 

<element name="carRental Company" nil lable="true" type="string"/> 
<element name="carCategory" nill able="true" type="string"/> 
<element name="carModel " nill able="true" type="string"/> 
<element name="pricePerWeek" type="float"/> 
<element name="pricePerDay" type="float"/> 
<element name="remoteId" type="int"/> 
</all> 
</complexType> 
</schema> 

Scenarios de gestion de reservation 

Le service Web de SW- Voyages est mis en ceuvre via six scenarios BPEL de gestion du processus de 
reservation. 

Ces scenarios sont decrits sous forme de classes Java annotees par des balises d' orchestration. Ces 
balises represented des metadonnees Java specifiees au format commentaires JavaDoc selon la 
specification JSR 175 (voir http://www.jcp.org/en/jsr/detail?id=175). 

Balises d'orchestration 

Les balises d'orchestration permettent d'exprimer : 

• le fait qu'une methode est asynchrone ; 

• le niveau de parallelisme de F execution du scenario (flot et sequences) ; 

• le fait qu'une methode est transactionnelle. 

Pour declarer une methode asynchrone, il suffit d'ajouter la ligne : 

/** @ws-conversation:mode async */ 

dans les commentaires JavaDoc de la methode. Par defaut, la valeur de @ws-conversation:mode est 
fixee a sync (methode synchrone). 

La gestion de processus paralleles est prise en charge via F utilisation de quatre balises : 

• la balise f 1 ow permet de definir un nombre fixe de sequences (branches paralleles), determine a la 
conception du scenario. Le flot se decrit ainsi : 

/** @bpel :flow */ 
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• la balise sequence decrit une branche a l'interieur d'un flot de la maniere suivante : 
/** @bpel :sequence */ 

• un nombre variable de sequences, connu seulement a l'execution, qui peut etre exprime ainsi : 

/** @bpel:flowN */ 

• la jointure des branches dans les Hots f 1 ow ou f 1 owN est decrite par la balise join. Celle-ci permet 
de specifier la condition de jointure sous forme d'une expression booleenne. Lorsque la condition 
est validee, les sequences pendantes sont annulees. La jointure se decrit ainsi : 

/** @bpel : join */ 

La declaration d'une methode transactionnelle s'effectue en ajoutant la balise 

/** @ws-transaction:attribute x */ 
ou la valeur x peut etre : 

• requi red : la methode doit etre associee a une transaction. Si la methode appelante est executee 
dans le cadre d'une transaction, la methode appelee s'execute dans le contexte de cette transac- 
tion. Sinon, le serveur d' orchestration cree une nouvelle transaction et associe la methode a ce 
nouveau contexte. 

• requi res-new : le serveur d' orchestration doit toujours creer une nouvelle transaction pour cette 
methode, meme si le service ou la methode appelante est deja associe a une transaction. 

• mandatory : la methode doit toujours s'executer dans le contexte d'une transaction existante. 
Si ce n'est pas le cas, le serveur d' orchestration leve une exception Transact!' onRequi red- 
Exception. 

• not-supported (par defaut) : la methode ne participe pas a une transaction. Si la methode est 
executee dans un contexte de transaction, cette derniere est suspendue le temps de l'execution de 
la methode. 

Parallelement a la declaration d'une methode transactionnelle, il est possible de prendre en compte 
les changements d'etat de la transaction en declarant deux methodes (optionnelles) qui, pour une 
methode transactionnelle nommee methode ( ) par exemple, seront nominees : 

• cancel Methode () : cette methode sera rappelee (callback) par le serveur d' orchestration si la 
transaction associee a la methode methode ( ) tombe en echec durant l'execution de celle-ci. 

• compensateMethode( ) : cette methode sera rappelee (callback) par le serveur d'orchestration si 
la transaction associee a la methode methodeO tombe en echec apres la fin d'execution de 
celle-ci. 

Ces deux methodes sont bien entendu tres utiles, notamment dans le cadre de transactions longues, 
oil le changement d'etat de la transaction peut intervenir dans un laps de temps plus ou moins long 
apres l'invocation initiale de la methode transactionnelle methodeO. Ces methodes sont optionnelles. 

Les scenarios BPEL presentes ci-apres illustrent des cas d'utilisation des balises d'orchestration et 
des methodes de gestion des etats des transactions. 
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Organisation des scenarios BPEL 

Les scenarios des quatre partenaires sont organises de maniere a conserver des registres locaux coherents entre 
eux. Afin de simplifier I'implementation, nous avons evite de mettre en oeuvre une persistance des registres en 
bases de donnees. 

Du fait que la demande de reservation se termine par une suppression de la reservation du registre local d'un 
partenaire (choix technique effectue pour eviter I'accroissement de memoire durant les tests), la gestion transac- 
tionnelle des operations entre les quatre partenaires doit se traduire, que les scenarios se passent bien ou se 
terminent mal, par un niveau constant de reservation en fin d'operation (fin materialisee soit par une annulation 
de demande, soit par une demande de reservation, pour toute demande de recherche initiee). 
Dans le cas present, les methodes cancel Methode et compensateMethode cherchent done a maintenir la cohe- 
rence des registres de reservation des quatre partenaires par des actions d'annulation ou de recreation de reser- 
vation dans les registres en fonction de la nature de Taction precedente a annuler ou a compenser. 
Par ailleurs, les methodes de compensation et d'annulation utilisees ici sont tres simplifies : elles ne font pas 
appel a de « vraies » actions de compensation ou d'annulation « metier », mais plutot a des actions executees 
dans une optique « technique » de coherence du registre. En effet, un echec du scenario de reservation (scenario 
book) de I'un des partenaires, par exemple, devrait se traduire par I'arret des autres reservations en cours de 
traitement et par I'annulation applicative (compensation) des reservations deja effectuees (scenario cancel). 



Scenario de demande de recherche de disponibilites 

Le scenario de demande de recherche de disponibilites (vous pouvez telecharger le code source sur le 
site www.editions-eyrolles.com) presente les particularites suivantes (fichier {$SW-VOYAGES_HOME%}\ 
ReservationService_Search. jbpel) : 

• La methode process est asynchrone (metadonnee @ws -conversation: mode async). 

• La methode organizeSearch, egalement asynchrone, est appelee par la methode process et 
demande ail serveur d'orchestration Fouverture d'une nouvelle transaction (metadonnee @ws-trans- 
acti on: attribute requi res-new) : chaque demande de recherche de disponibilites du client 
declenche une nouvelle transaction metier. Les scenarios invoques dans le cadre de cette methode, 
dotes de capacites transactionnelles (transaction aware), sont automatiquement enroles en tant que 
participants a la transaction. 

• La methode organizeSearch decrit un not (metadonnee @bpel :flow) de trois sequences paralleles 
(metadonnee @bpel sequence) : chacune de ces branches est chargee de l'invocation asynchrone du 
scenario de demande de recherche de disponibilites des partenaires SW-Air, SW-H6tels et SW- 
Voitures. La methode ne se termine que lorsque les trois scenarios invoques ont repondu (pas de 
condition de jointure). Le scenario de SW-Air est toujours invoque. En revanche, les scenarios de 
SW-H6tels et SW-Voitures ne sont invoques que si le client a exprime un souhait de reservation 
hoteliere et/ou automobile. 

• La methode asynchrone cancel OrganizeSearch est declaree et susceptible d'etre appelee par le 
serveur d'orchestration soit en cas d'erreur dans la methode organizeSearch, soit en cas d'erreur 
dans les sous-transactions generees lors de l'invocation des scenarios des trois partenaires de SW- 

Voyages. 

• Le scenario ne presente pas de methode compensateOrganizeSearch car cela n'a pas de sens a ce 
niveau (scenario racine et processus appelant non transactionnel) : soit la methode process (et les 
methodes incluses) s'est bien terminee et le resultat est renvoye au client, soit elle s'est mal passee 
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et la methode cancel OrganizeSearch a ete declenchee. Dans le cas ou Fexception s'est produite 
durant ou apres l'invocation des scenarios de demande de recherche de disponibilites des parte- 
naires, le serveur d'orchestration invoque les methodes d'annulation ou de compensation de ces 
scenarios selon leur etat d'execution au moment de l'intermption. 

Scenario de recuperation des disponibilites aeriennes 

Le scenario de recuperation des disponibilites aeriennes (vous pouvez telecharger le code source sur le site 
www.editions-eyrolles.com) presente les particularites suivantes (fichier {%SW-V0YAGES_H0ME3!}\ 
ReservationService_GetAi r. jbpel) : 

• La methode process est asynchrone ( metadonnee @ws-conversati on: mode async). 

• La methode organizeGetAvailabilities, egalement asynchrone, est appelee par la methode 
process et demande au serveur d'orchestration l'ouverture d'une nouvelle transaction (meta- 
donnee @ws- transact ion attribute requires -new) : chaque demande de recuperation de disponi- 
bilites aeriennes du client declenche une nouvelle transaction metier. Les scenarios invoques dans 
le cadre de cette methode, dotes de capacites transactionnelles, sont automatiquement enroles en 
tant que participants a la transaction. 

• La methode organizeGetAvailabilities decrit un flot (metadonnee @bpel:flow) d'une seule 
sequence (metadonnee Obpel : sequence) chargee de l'invocation asynchrone du scenario de 
demande de recuperation de disponibilites aeriennes du partenaire SW-Air. La methode se termine 
lorsque le scenario de SW-Air (toujours invoque) a renvoye son resultat. 

• La methode asynchrone cancel OrganizeGetAvailabilities est declaree et susceptible d'etre 
appelee par le serveur d'orchestration soit en cas d'erreur dans la methode organizeGetAvailabi- 
lities, soit en cas d'erreur dans la sous-transaction generee lors de l'invocation du scenario de 
SW-Air. Dans la cas present, nous avons choisi une option radicale : une erreur de recuperation des 
disponibilites se traduit par une suppression de la demande du registre local. Le client est alors 
contraint de soumettre une nouvelle demande de recherche de disponibilites. 

• Le scenario ne presente pas de methode compensateOrganizeGetAvai labilities car cela n'a pas 
plus de sens a ce niveau que pour le scenario precedent. 

Scenario de recuperation des disponibilites hotelieres 

Le scenario de recuperation des disponibilites hotelieres (vous pouvez telecharger le code source sur 
le site www.editions-eyrolles.com) offre des particularites strictement identiques a celles des scena- 
rios de recuperation des disponibilites aeriennes et automobiles (fichier {%SW-VOYAGES_HOME%}\ 
ReservationService_GetHotel .jbpel). 

Scenario de recuperation des disponibilites automobiles 

Le scenario de recuperation des disponibilites automobiles (vous pouvez telecharger le code source 
sur le site www.editions-eyrolles.com) presente des caracteristiques strictement identiques a celles 
du scenario de recuperation des disponibilites aeriennes (fichier {%SW-VOYAGES_HOME%}\ 
ReservationService_GetCar. jbpel). 

II n'est invoque par la partie cliente de l'application de reservation que si l'utilisateur final a exprime 
un souhait de reservation automobile. 
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Scenario de reservation d'une demande de disponibilites 

Le scenario de reservation d'une demande de disponibilites (vous pouvez telecharger le code source sur 
le site www.editions-eyrolles.com) presente les caracteristiques suivantes (fichier {%SW-VOYAGES_HOME%}\ 

ReservationService_Book. jbpel) : 

• Lamethode process est asynchrone (metadonnee @ws-conversation:mode async). 

• La methode organi zeBook, egalement asynchrone, est appelee par la methode process et demande 
au serveur d' orchestration l'ouverture d'une nouvelle transaction (metadonnee @ws-transac- 
tion:attribute requi res-new) : chaque demande de reservation de disponibilites du client 
declenche une nouvelle transaction metier. Les scenarios invoques dans le cadre de cette methode, 
dotes de capacites transactionnelles, sont automatiquement enroles en tant que participants a la 
transaction. 

• La methode organi zeBook decrit un flot (metadonnee Obpel :flow) de trois sequences paralleles 
(metadonnee @bpel : sequence) : chacune de ces branches est chargee de l'invocation asynchrone du 
scenario de reservation d'une demande de disponibilites des partenaires SW-Air, SW-H6tels et 
SW-Voitures. La methode ne se termine que lorsque les trois scenarios invoques ont repondu (pas 
de condition de jointure). Le scenario de SW-Air est toujours invoque. En revanche, les scenarios 
de SW-H6tels et SW-Voitures ne sont invoques que si le client a exprime un souhait de reservation 
hoteliere et/ou automobile lors de sa demande initiale. 

• La methode asynchrone cancel Organi zeBook est declaree et susceptible d'etre appelee par le 
serveur d' orchestration soit en cas d'erreur dans la methode organi zeBook, soit en cas d'erreur dans 
les sous-transactions generees lors de l'invocation des scenarios des trois partenaires de SW- 

Voyages. 

• Le scenario ne presente pas de methode compensateOrgani zeBook car cela, comme dans les autres 
scenarios de SW- Voyages, n'a pas de sens a ce niveau. 

Scenario d'annulation de recherche de disponibilites 

Le scenario d'annulation de recherche de disponibilites (fichier {$SW-VOYAGES_HOME%}\ 
ReservationService_Cancel .jbpel) presente les particularites qui suivent (vous pouvez telecharger le 
code source sur le site www.editions-eyrolles.com) : 

• Lamethode process est asynchrone (metadonnee @ws-conversation:mode async). 

• La methode organi zeCancel , egalement asynchrone, est appelee par la methode process et demande 
au serveur d' orchestration l'ouverture d'une nouvelle transaction (metadonnee @ws-trans- 
action:attribute requi res-new) : chaque demande d'annulation de recherche de disponibilites du 
client declenche une nouvelle transaction metier. Les scenarios invoques dans le cadre de cette 
methode, dotes de capacites transactionnelles, sont automatiquement enroles en tant que participants 
a la transaction. 

• La methode organi zeCancel decrit un flot (metadonnee @bpel : f 1 ow) de trois sequences paralleles 
(metadonnee @bpel : sequence) : chacune de ces branches est chargee de l'invocation asynchrone du 
scenario d'annulation d'une demande de recherche de disponibilites des partenaires SW-Air, SW- 
Hotels et SW-Voitures. La methode ne se termine que lorsque les trois scenarios invoques ont 
repondu (pas de condition de jointure). Le scenario de SW-Air est toujours invoque. En revanche, 
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les scenarios de SW-H6tels et SW-Voitures ne sont invoques que si le client a exprime un souhait 
de reservation hoteliere et/ou automobile lors de sa demande initiale. 

• La methode asynchrone cancel OrganizeCancel est declaree et susceptible d'etre appelee par le 
serveur d' orchestration soit en cas d'erreur dans la methode organizeCancel soit en cas d'erreur 
dans les sous-transactions generees lors de l'invocation des scenarios des trois partenaires de SW- 

Voyages. 

• Le scenario ne presente pas de methode compensateOrgani zeCancel car cela, comme dans les autres 
scenarios de SW- Voyages, n'a pas de sens a ce niveau. 

Descripteurs de deploiement des scenarios de gestion de reservation 

Chacun des six scenarios de gestion de reservation est associe a un descripteur de deploiement au 
format XML. Ces descripteurs peuvent comporter certaines informations de parametrage necessaires 
au fonctionnement du scenario correspondant. 

Le descripteur contient au minimum un element bpel -scenario src dont la valeur represente le nom 
qualifie de la classe Java qui implemente de scenario. 

Descripteur de deploiement du scenario de demande de recherche de disponibilites 

Le descripteur de deploiement du scenario de demande de recherche de disponibilites (fichier {%SW- 
V0YAGES_H0ME3!}\SWVoyages_Reservation_Search.xml) se presente ainsi : 

<?xml version="1.0" encoding="UTF-8"?> 

<bpel -scenario src= "com. cxdn.samples.swvoy ages. ReservationService_Search"> 

properties id="SW-Air_ReservationService"> 

<property name="location"> 
http:/ /www. sw- voyages. com :9700/default/SWAi r_Reservation_Search 

</property> 
</properties> 
properties id="SW-Hotel s_ReservationService"> 

<property name="location"> 
http:/ /www. sw- voyages. com :9700/def a ult/SWHotels_Reservation_Search 

</property> 
</properties> 
<properties id="SW-Voitures_ReservationService"> 

<property name="location"> 
http: //www. sw- voyages. com :9700/default/SWVoitures_Reservation_Search 

</property> 
</properties> 
</bpel -scenario) 

Descripteur de deploiement du scenario de recuperation des disponibilites aeriennes 

Le descripteur de deploiement du scenario de recuperation des disponibilites aeriennes (fichier 
{%SW-VOYAGES_HOME%}\SWVoyages_Reservation_GetAir.xml) se presente de la maniere 
suivante : 

|<?xml version="1.0" encoding="UTF-8"?> 
<bpel -scenario src=" com. cxdn.samples.swvoy ages. ReservationService_GetAir"> 
<properties id="SW-Air_ReservationService"> 
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<property name="location"> 
http://www.sw- voyages .com:9700/default/SWAir_Reservation_Get 

</property> 
</properties> 
</bpel -scenario> 

Descripteur de deploiement du scenario de recuperation des disponibilites hotelieres 

Le descripteur de deploiement du scenario de recuperation des disponibilites hotelieres (fichier 
{KW-VOYAGES_HOME£}\SWVoyages_Reservation_GetHotel .xml) se presente ainsi : 

<?xml version="1.0" encoding="UTF-8"?> 

<bpel -scenario src=" com. cxdn.samples.swvoy ages. ReservationService_GetHotel "> 

<properties id="SW-Hotels_ReservationService"> 

<property name="location"> 
http : //www. sw- voyages. com :9700/def a ult/SWHotels_Reservation_Get 

</property> 
</properties> 
</bpel -scenario> 

Descripteur de deploiement du scenario de recuperation des disponibilites automobiles 

Le descripteur de deploiement du scenario de recuperation des disponibilites automobiles (fichier 
{£SW-VOYAGES_HOME£}\SWVoyages_Reservation_GetCar.xml) contient les proprietes qui suivent : 

<?xml version="1.0" encoding="UTF-8"?> 

<bpel -scenario src="com.cxdn.samples.swvoyages.ReservationService_GetCar"> 

<properties id="SW-Voitures_ReservationService"> 

<property name="location"> 
http://www.sw- voyages . com:9700/defaul t/SWVoitures_Reservation_Get 

</property> 
</properties> 
</bpel -scenario> 

Descripteur de deploiement du scenario de reservation d'une demande de disponibilites 

Le descripteur de deploiement du scenario de reservation d'une demande de disponibilites (fichier 
{%SW-VOYAGES_HOME%}\SWVoyages_Reservation„Book.xml) contient les proprietes qui suivent : 

<?xml version="1.0" encoding="UTF-8"?> 

<bpel -scenario src=" com. cxdn.samples.swvoy ages. ReservationService_Book"> 

properties id="SW-Air_ReservationService"> 

<property name="location"> 
http://www.sw- voyages . com:9700/defaul t/SWAir_Reservation_Book 

</property> 
</properties> 
<properties id="SW-Hotels_ReservationService"> 

<property name="location"> 
http://www.sw- voyages .com:9700/default/SWHotels_Reservation_Book 

</property> 
</properties> 
<properties id="SW-Voitures_ReservationService"> 

<property name="location"> 
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http:/ /www. sw- voyages. com: 9700 /def a ult/SWVoitures_Reservation_Book 
</property> 
</properties> 
</bpel -scenario> 

Descripteur de deploiement du scenario d'annulation de recherche de disponibilites 

Le descripteur de deploiement du scenario d'annulation de recherche de disponibilites (fichier {%SW- 
VOYAGES_HOME%}\SWVoyages_Reservation_Cancel .xml) se presente ainsi : 

<?xml version="1.0" encoding="UTF-8"?> 

<bpel -scenario src=" com. cxdn.samples.swvoy ages .ReservationService_Cancel "> 

properties id="SW-Air_ReservationService"> 

<property name="location"> 
http: //www. sw- voyages. com :9700/def a ult/SWAi r_Reservation_Cancel 

</property> 
</properties> 
<properties id="SW-Hotel s_ReservationService"> 

<property name="location"> 
http :/ /www. sw- voyages. com: 9700 /def a ult/SWHotel s_Reservation_Cancel 

</property> 
</properties> 
<properties id="SW-Voitures_ReservationService"> 

<property name="location"> 
http: //www. sw- voyages. com :9700/default/SWVoitures_Reservation_Cancel 

</property> 
</properties> 
</bpel -scenario> 



Architecture statique 

L'architecture decrite ici est de type statique : les descripteurs de deploiement presentes component les adresses 
d'acces aux scenarios des partenaires de SW-Voyages, codees directement dans les descripteurs. Une transfor- 
mation en architecture dynamique necessiterait de pouvoir disposer d'une API de modification de ces descripteurs. 



Classes de support aux scenarios 

Les classes d'implementation des scenarios utilisent les memes classes de servitude ou de support que 
celles utilisees chapitre 23. Celles-ci sont parfois legerement modifiees pour des raisons inherentes au 
fonctionnement du serveur Collaxa dans sa version actuelle. 

Le paquetage de ces classes devient : com. cxdn.samples.swvoy ages, reservation. 

Classe ReservationManager.java 

La classe d'implementation d'un registre local des reservations (fichier {%SW-V0YAGES_H0ME%}\Reser- 
vationManager.java), qui conserve les informations des sessions ouvertes depuis l'ouverture du 
serveur duplications, demeure inchangee par rapport a la description effectuee chapitre 23. Cette 
classe etend la classe Hashtable du SDK (vous pouvez telecharger le code source sur le site 
www.editions-eyrolles.com). 
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La classe d'interface (fichier {%SW-VOYAGES_HOME%}\ReservationRegistry.java) n'est egalement pas 
modifiee. 

Classe Reservation. Java 

La reservation (fichier { £SW- VOYAGES _H0ME% }\Reservati on. j a va) conserve les informations relatives a 
la demande de Futilisateur (caracteristiques du voyage) d'une part, et les disponibilites aeriennes, 
automobiles et hotelieres communiquees par les partenaires d' autre part : elle reste quasiment identi- 
que a la description faite chapitre 23 (vous pouvez telecharger le code source sur le site 
www.editions-eyrolles.com). 

La classe est simplement modifiee pour importer les classes de disponibilites qui sont maintenant 
generees par Fenvironnement de developpement de Collaxa (voir ci-apres). La ligne d'importation 
ajoutee est : 

import com. cxdn.samples.swvoy ages.*; 

Classes AirAvailability.java, CarAvailability.java et HotelAvailability.java 

Les disponibilites gerees par SW- Voyages, aeriennes (classe AirAvailability.java), automobiles 
(classe CarAvailability.java) ou hotelieres (classe HotelAvailability.java) sont maintenant gene- 
rees automatiquement, a partir des schemas XML presentes precedemment lors de la construction et 
du deploiement des scenarios. 

Classe Reservation Exception. Java 

La classe d'exception generique utilisee par l'ensemble des classes de servitude (fichier {£SW- 
VOY AGESJOME%}\ Res ervat ion Except ion. Java) est simplifiee par rapport a celle utilisee chapitre 23. La 
variable rootCause de type Throwable ainsi que les methodes associees sont supprimees car elles 
semblent poser un probleme de serialisation au moteur d'execution (vous pouvez telecharger les 
codes source sur le site www.editions-eyrolles.com). 

Construction et deploiement des scenarios 

Collaxa utilise un utilitaire cxant.bat, similaire a l'utilitaire Ant de la communaute Apache, pour 
compiler l'application Web. Cet outil est localise dans le repertoire (%COLLAXA_HOME£}\cxdk\bin. II 
predefinit les taches (au sens Ant) bpelc, schemac et wsdlc specifiques a l'environnement Collaxa 
(voir ci-apres). 

L'utilitaire prend un fichier build. xml en parametre (fichier {%SW-VOYAGES_HOME%}\build.xml). Ce 
fichier est en fait un descripteur de construction. 

Celui de l'application Web de SW- Voyages se presente ainsi : 

<?xml version="1.0"?> 

<project name="ReservationService" default="main" basedir="."> 
<property name="deploy" value="true"/> 
<property name="rev" value="1.0"/> 

<property name="out" valuer" ${CXHome}/server-default/cl asses "/> 
<target name="main"> 
<schemac input="${basedir}/Book.xsd" out="${out}"/> 
<schemac input="${basedir}/Cancel .xsd" out="${out}"/> 
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<schemac i 
<schemac i 
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nput= 
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rev= 
<bpel c 

rev= 
<bpelc 

rev= 
<bpel c 

rev= 
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rev= 
<bpel c 

rev= 
</target> 
</project> 



$(rev 
input 
${rev 
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nput="${basedir}/GetAir.xsd" out="${out}"/> 
nput="${basedir}/GetCar.xsd" out="${out}"/> 
; "${basedir}/GetHotel .xsd" out="${out}"/> 
"${basedir}/Search.xsd" out="${out}"/> 
"${basedi r}/AirAvailabil i ties. xsd" out="${out}"/> 
"${basedi r}/CarAvailabil i ties. xsd" out="${out}"/> 
■"${basedir} /Hotel Avail abilities. xsd" out="${out}"/> 

"${basedir}" destdir="${out}" includes^"*. java"/> 

${basedir}/SWVoyages_Reservation_Book.xml " 
deploy="${deploy}"/> 

${basedir}/SWVoyages_Reservation_Cancel .xml " 
deploy="${deploy}"/> 

$(basedir}/SWVoyages_Reservation_GetAi r.xml " 
deploy="${deploy}"/> 

${basedir}/SWVoyages_Reservation_GetCa r.xml " 
dep1oy="${deploy}"/> 

${basedir}/SWVoyages_Reservation_GetHotel .xml " 
deploy="${deploy}"/> 

${basedir}/SWVoyages_Reservation_Search.xml " 
deploy="${deploy}"/> 



La construction de F application Web est realisee en quatre etapes : 

1. generation, via l'utilitaire schemac, de classes de representation Java a partir des six schemas 
XML de description des documents d'invocation des scenarios ; 

2. generation, via l'utilitaire schemac, des classes de representation Java correspondant aux trois 
schemas XML de description des disponibilites produites par ces scenarios ; 

3. compilation, par le compilateur standard javac, des classes Java de servitude et de support utilisees 
par les scenarios BPEL ; 

4. generation, via l'utilitaire bpel c, des classes Java executables a partir des six scenarios BPEL. 

L'utilitaire schemac permet, a partir d'un schema XML ou WSDL (incorporant un schema XML), de 
generer et de compiler un ensemble de classes Java associees au document metier decrit. L utilisation 
de cet outil, pour un type complexe, provoque la generation de plusieurs classes Java associees (voir 
son utilisation dans les scenarios) : 

• une classe d'interface qui represente la structure du type ; 

• une implementation du schema sous forme d'un gestionnaire de persistance et d'une classe de 
serialisation/deserialisation (marshaller XML/SOAP) utilisee par 1' infrastructure SOAP sous- 
jacente (Apache Axis 1.0) ; 

• une classe de fabrication (factory) dediee a la construction des instances de documents de ce type ; 

• une classe d' exception associee a ce type ; 

• une classe interne necessaire au produit. 
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L'utilitaire bpel c permet, a partir d'un scenario BPEL ou d'un descripteur de deploiement BPEL, de 
generer et de compiler un ensemble de classes Java associees au scenario. En outre, il genere la 
description WSDL qui permet d'exposer le scenario et de Finvoquer comme un service Web, ainsi 
qu'une interface de delegation qui autorise une invocation du scenario a partir d'une JSP, d'un servlet 
ou d'une classe Java. 

II est possible de faire cohabiter plusieurs versions d'un meme scenario dans l'environnement 
d'execution Collaxa, via l'usage de l'attribut rev de la tache bpelc : ici, l'attribut rev="${rev}" refe- 
rence une propriete dont la valeur est fixee a 1 . pour tous les scenarios. 

L'attribut deploy de la tache bpelc permet de preciser qu'apres compilation, le scenario doit etre 
deploye automatiquement dans le container d'execution. C'est ici le cas et les fichiers .jar associes 
aux scenarios compiles seront done deployes dans le repertoire {%COLLAXA_HOME&}\server-default\ 
scenarios, e'est-a-dire les fichiers suivants : 

bpel_SWVoyages_Reservation_Book_l .0. jar ; 

bpel_SWVoyages_Reservation_Cancel_1.0. jar ; 

bpel_SWVoyages_Reservation_GetAi r_l .0. jar ; 

bpel_SWVoyages_Reservation_GetCar_1.0. jar ; 

bpel_SWVoyages_Reservation_GetHotel_l .0. jar ; 

bpel_SWVoyages_Reservation_Search_1.0. jar. 

La construction de l'application est lancee, a partir d'une invite de commandes, et apres s'etre placee 
dans le repertoire {%SW-V0YAGES_H0ME%}, par la commande : 

| C:\Collaxa_2.0\cxdk\bin\cxant 

Test des scenarios BPEL 

Apres construction et deploiement des scenarios BPEL, il est possible de les tester un par un. Pour 
cela, il faut demarrer la console Collaxa. Celle-ci est accessible a partir d'un navigateur Internet, 
via l'URL http://www.sw-voyages.conT.9700/collaxa. La console se presente telle que l'illustre la 
figure 26-4. 

La console presente trois onglets principaux qui presentent : 

• la liste des scenarios deployes : celle-ci affiche en haut de la page les instances de scenarios en 
cours d'execution et en bas les instances terminees ; 

• la liste anti-chronologique des instances de scenarios qui peut etre filtree selon divers criteres dont 
le numero d'instance, le modele de scenario, la date de creation, l'etat de l'instance, etc. ; 

• la liste chronologique des activites executees dans le cadre des instances de scenarios qui peut 
egalement etre filtree selon divers criteres dont le type d'activite, l'etat de l'activite, etc. 
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Figure 26-4 

Console du serveur BPEL Orchestration Server de Collaxa. 
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L'ecran figure 26-4 presente 1' ensemble des scenarios (les six scenarios de SW- Voyages et les douze 
de SW-Air, SW-H6tels et SW-Voitures presentes dans les sections qui suivent) developpes dans le 
cadre de cette derniere generation du logiciel de reservation de SW- Voyages et ses partenaires. Cinq 
instances de scenarios sont terminees et quatre instances sont en cours d' execution. 

Pour tester un scenario, il suffit de cliquer sur le scenario choisi dans la partie gauche de l'ecran. Cela 
a pour effet de faire apparaitre un formulaire de saisie qui reflete le(s) parametre(s) de la methode 
process du scenario. Par exemple, un clic sur le scenario de recherche de disponibilites de SW- Voyages 
(le dernier de la liste) provoque l'affichage de l'ecran presente figure 26-5. 

Cet ecran presente quatre sous-onglets qui permettent d'afficher : 

• le formulaire de saisie du(des) parametre(s) du scenario ; 

• les descriptions WSDL du scenario expose comme un service Web ; 

• le contenu du descripteur de deploiement du scenario ; 

• le code source Java du scenario BPEL. 
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Figure 26-5 

Formulaire de saisie des pararnetres du scenario de recherche de disponibUites de S W- Voyages. 



Ce dernier onglet affiche le code source Java (JBPEL) du scenario et dispose d'un commutateur qui 
permet d'afficher, par incrustation, le modele BPEL4WS sous-jacent. Par exemple, une partie du 
code source du scenario de recherche de disponibilites est illustree figure 26-6. 

On reconnait, dans cette portion de code, les balises scope, sequence, f aul tHandl ers ou catch de la 
syntaxe BPEL4WS. A cette collection de balises ont ete ajoutees des balises propres a une exten- 
sion specifique au serveur de Collaxa prefixee bpelx : cette syntaxe complementaire fait notam- 
ment apparaitre des balises exec et subflow. La balise exec est importante car elle permet de faire 
le lien avec un langage de programmation (ici Java) charge d'implementer les taches decrites dans 
le scenario. 
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Figure 26-6 

Correspondence JBPEL/BPEL4WS du scenario de recherche de disponibilites de SW- Voyages. 



Le declenchement du test du scenario, apres saisie du(des) parametre(s) du formulaire et utilisation 
du bouton Ini ti ate Fl ow, provoque l'affichage d'un ecran dans lequel il est possible de choisir entre 
la presentation visuelle du flot d'execution, un ecran d'affichage de la piste d'audit de Finstance 
generee ou un ecran de verification de Finstance (debug). L'affichage du flot presente un ecran du 
meme type que celui montre figure 26-7. 

Cet ecran comporte cinq onglets qui permettent : 

• de visualiser le flot d'execution de Finstance du scenario choisi ; 

• d'inspecter la piste d'audit associee a Finstance (dates et heures de debut et de fin des taches, 
signalisation des transactions et des etats associes, etc.) ; 

• d'inspecter le code execute, la valeur des variables, etc. ; 

• d'afficher la liste des activites associees a cette instance et en cours d'execution ou d'attente ; 

• de visualiser la liste des transactions et des participants a ces transactions, ainsi que Fetat con - es- 
pondant. 
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Figure 26-7 

Representation du flot a" execution du scenario de recherche de disponibilites de SW- Voyages. 

L'ecran ci-avant affiche une portion de la representation visuelle du flot du scenario de recherche de 
disponibilites de SW- Voyages, dans laquelle on peut voir le declenchement en parallele des scenarios 
transactionnels asynchrones de recherche de disponibilites des trois partenaires de SW- Voyages. 

La console du serveur de Collaxa presente done tous les outils necessaires pour tester les scenarios 
BPEL de maniere autonome (mode standalone). Bien entendu, les scenarios testes peuvent inclure 
des invocations synchrones ou asynchrones de services Web externes. Lorsque les tests sont juges 
concluants, ceux-ci peuvent etre poursuivis par l'integration avec la partie cliente de 1' application 
(voir la section « Scenario n°4 » du chapitre 22). 



Applications Web des partenaires de SW-Voyages 

Nous avons vu, en debut de chapitre, que pour beneficier des fonctionnalites transactionnelles du 
produit, il est imperatif que les services de reservation des quatre partenaires reposent sur une imple- 
mentation des trois specifications concernees (BPEL4WS, WS -Coordination et WS-Transaction). 
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D'autre part, du fait de l'etat actuel de cette technologie, le deploiement des composants applicatifs 
de chacun des partenaires ne peut etre realise qu'a Faide d'un seul et meme produit (le serveur 
Collaxa), disponible uniquement en version beta. 

Ces choix nous permettent notamment d'eviter des problemes d'interoperabilite effective, domaine 
dans lequel tout reste a faire. 

Comme dans les precedents chapitres, seule 1' implementation de la centrale de reservation SW-Air 
sera reproduite dans ce scenario d' architecture n°4. En effet, les implementations des deux autres 
centrales de reservation SW-H6tels et SW-Voitures sont calquees sur le meme modele et leur presen- 
tation n'apportera pas de precisions supplementaires. 

L'arborescence de l'application Web de la societe SW-Air (repertoire reservation_sw-air) est, 
comme dans le cas de SW- Voyages, differente de celle du scenario d' architecture n°l et se presente 
done telle que Fillustre la figure 26-8. 

Cette arborescence comprend dix-huit fichiers : 

• unfichier build, xml utilise par Futilitaire cxant.bat pour compiler l'application Web ; 

• quatre scenarios BPEL en format Java specifique a Collaxa (fichiers d'extension . jbpel ) ; 

• quatre descripteurs de deploiement des scenarios correspondants (fichiers d'extension . xml ) ; 

• quatre schemas de description des documents d'invocation des scenarios de SW-Air (fichiers 
d'extension .xsd) ; 

• un schema de description du document renvoye par la methode de recuperation des disponibilites 
aeriennes de SW-Air (fichier d'extension .xsd) ; 

• quatre classes Java de support aux scenarios de SW-Air (fichiers d'extension .Java). 

Dans la suite de ce chapitre, le repertoire qui contient cette arborescence, localise a 
{%C0LLAXA_H0ME2}\cxdk\samples\reservation_sw-air, est designe par la variable {%SW-AIR_HOME%}. 

Partie serveur de l'application Web des partenaires de SW-Voyages 

La partie serveur de l'application Web des partenaires de SW-Voyages est elle aussi entierement 
realisee en technologie Java utilisee par le serveur BPEL Orchestration Server de Collaxa. La classe 
ReservationService. Java du chapitre 23 est remplacee par quatre scenarios BPEL : 

• ReservationService_Search. jbpel : demande coordonnee de recherche des disponibilites 
aeriennes de SW-Air ; 

• ReservationService_Get. jbpel : recuperation coordonnee des disponibilites aeriennes de SW- 
Air; 

• ReservationService_Book. jbpel : confirmation coordonnee d'une demande de reservation des 
disponibilites aeriennes de SW-Air ; 

• ReservationService_Cancel .jbpel : annulation coordonnee d'une demande de reservation des 
disponibilites aeriennes de SW-Air. 

Ces scenarios represented les elements principaux de l'application du cote serveur. 
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Figure 26-8 

Arborescence de I 'application Web de la societe SW-Air. 



Schemas XML des requetes d' invocation 

Chacun de ces scenarios est active via remission d'un document correspondant qui contient les para- 
metres necessaires au declenchement du scenario. Ce document est decrit sous forme d'un schema 
XML. 
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Schema XML de la requete search 

La requete de demande de recherche de disponibilites est ainsi redigee (fichier {%SW-AIR_HOME%}\ 

Search. xsd) : 

<?xml version="1.0"?> 

<schema targetNamespace="http: //samples .cxdn.com/swair/search" 
xmlns:tns=" http://samples.cxdn.com/swair/search" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="SearchRequest"> 
<complexType> 
<all> 
<element name="passengers" type="int"/> 
<element name="from" type="string"/> 
<element name="to" type="string"/> 
<element name="roundTrip" type="boolean"/> 
<element name="departureDay" type="int"/> 
<element name="departureMonth" type="int"/> 
<element name="departureYear" type="int"/> 
<element name="arri valDay" type="int"/> 
<element name="arri valMonth" type="int"/> 
<element name="arrivalYear" type="int"/> 
<element name="remoteId" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="SearchFailure"> 
<complexType> 
<all> 
<element name="searchRequest" type="tns:SearchRequest" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete getAirAvailabilities 

La requete de demande de recuperation de disponibilites aeriennes se decrit ainsi (fichier 

{*SW-AIR_HOME«}\Get.xsd) : 

<?xml version="1.0"?> 

<schema targetNamespace="http: //samples .cxdn.com/swair/getavail abilities" 
xmlns:tns="http: //samples .cxdn.com/swair/getavailabil ities" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="GetAvailabil itiesRequest"> 
<complexType> 
<all> 

<element name="reservationId" type="int"/> 
</all> 
</complexType> 
</element> 
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<element name="GetAvailabil i ti esFai 1 ure"> 

<complexType> 
<all> 
<element name="getAvail abil itiesRequest" 
type="tns:GetAvailabilitiesRequest" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete book 

La requete de demande de reservation s'exprime de la maniere suivante (flchier {%SW-AIR_HOME%}\ 
Book.xsd) : 

<?xml version="1.0"?> 

<schema target Namespace="http:/ /samples. cxdn.com/swai r/book" 
xmlns :tns="http:/ /samples. cxdn.com/swai r/book" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="BookRequest"> 
<complexType> 
<all> 
<element name="reservationId" type="int"/> 
<element name="departureAvailabilityId" type="int"/> 
<element name="arrival Avail abil ityld" type="int"/> 
</all> 
</complexType> 
</element> 

<element name="BookFailure"> 
<complexType> 
<all> 
<element name= 
<element name= 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML de la requete cancel 

La requete d'annulation de recherche de disponibilites est la suivante (fichier {%SW-AIR_HOME%}\ 
Cancel .xsd) : 

<?xml version="1.0"?> 

<schema target Namespace="http:/ /samples. cxdn.com/swai r /cancel " 
xmlns :tns="http:/ /samples. cxdn.com/swair /cancel " 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<element name="Cancel Request"> 
<complexType> 
<all> 
<element name="reservation!d" type="int"/> 



'bookRequest" type="tns:BookRequest" /> 
'message" type="string" /> 
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</all> 
</complexType> 
</element> 

<element name="Cancel Failure"> 
<complexType> 
<all> 
<element name="cancel Request" type="tns:Cancel Request" /> 
<element name="message" type="string" /> 
</all> 
</complexType> 
</element> 
</schema> 

Schema XML des disponibilites aeriennes 

Le scenario de recuperation des disponibilites aeriennes renvoie une stracture complexe de donnees. 
Celle-ci est retournee a 1' application cliente sous forme d'un document formalise par un schema 
XML. 

Les disponibilites aeriennes s'expriment de la maniere suivante (fichier {%SW-AIR„HOME%}\Avai labi- 
1 ities.xsd) : 

<?xml version="1.0"?> 

<schema targetNamespace="http: //samples .cxdn.com/swair" 
xml ns : tns="http : //sampl es . cxdn . com/swai r" 
xmlns=" http://www.w3.org/2001/XMLSchema"> 
<complexType name="ArrayOfAirAvail abil ity"> 
<sequence> 

<element ref="tns:AirAvailabil ity" maxOccurs=" unbounded "/> 
</sequence> 
</complexType> 

<complexType name="AirAvailabil ity"> 
<all> 
<element name="id" type="int"/> 

<element name="ai rCompany" nil lable="true" type="string"/> 
<element name="flightNumber" nill able="true" type="string"/> 
<element name="departureAi rport" nil 1 able="true" type="string"/> 
<element name="arrival Airport" nil lable="true" type="string"/> 
<element name="departureHour" nill able="true" type="string"/> 
<element name="arrivalHour" nil lable="true" type="string"/> 
<element name="di rection" type="boolean"/> 
<element name="price" type="float"/> 
<element name="remoteId" type="int"/> 
</all> 
</complexType> 
</schema> 
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Scenarios de gestion de reservation 

L' application Web de SW-Air est decrite sous la forme de quatre scenarios BPEL de gestion de la 
reservation. II en va de meme pour les applications Web des partenaires SW-H6tels et SW-Voitures 
qui ne sont pas reproduites ici. 

Scenario de demande de recherche de disponibilites aeriennes 

Le scenario de demande de recherche de disponibilites aeriennes (vous pouvez telecharger le code 
source sur le site www.editions-eyrolles.com) presente les caracteristiques qui suivent (fichier 

{%SW-AIR_HOME%}\ReservationService_Search.jbpel) : 

• Lamethode process est asynchrone (metadonnee @ws-conversation:mode async). 

• Lamethode process est toujours associee a une transaction (metadonneeSws -transaction: attri- 
bute requi red). Si la methode appelante est executee dans le cadre d'une transaction (ce qui est le 
cas de l'application de reservation de SW- Voyages), la methode appelee s'execute dans le contexte 
de cette transaction. Dans le cas contraire, le serveur d' orchestration cree une nouvelle transaction 
et associe la methode a ce nouveau contexte. Chaque demande de recherche de disponibilites 
aeriennes adressee a SW-Air s'execute dans le contexte transactionnel de son client ou declenche 
une nouvelle transaction metier interne a SW-Air. Le scenario, ainsi dote de capacites transaction- 
nelles, est ici automatiquement enrole en tant que participant a la transaction initiee par le scenario 
appelant de SW- Voyages. 

• La methode asynchrone cancel Process est declaree et susceptible d'etre appelee par le serveur 
d' orchestration en cas d'erreur durant le traitement de la methode process. 

• La methode asynchrone compensateProcess est egalement decrite et pourra etre appelee par le 
serveur d'orchestration lorsque le traitement de la methode process se sera bien termine mais 
qu'une erreur aura ete remontee par l'un des participants a la transaction appelante initiee par SW- 
Voyages. 

Scenario de recuperation des disponibilites aeriennes 

Le scenario de recuperation des disponibilites aeriennes (vous pouvez telecharger le code source sur 
le site www.editions-eyrolles.com) presente les particularites suivantes (fichier (%SW-AIR_HOME%}\ 
ReservationService_Get. jbpel) : 

• Lamethode process est asynchrone (metadonnee @ws -conversation: mode async). 

• La methode process est toujours associee a une transaction (metadonnee @ws -t ransacti on : attri bute 
requi red), comme dans le scenario de recherche de disponibilites. Chaque demande de recuperation 
de disponibilites aeriennes adressee a SW-Air s'execute dans le contexte transactionnel de son client 
ou declenche une nouvelle transaction metier interne a SW-Air. Le scenario est ici aussi automatique- 
ment enrole en tant que participant a la transaction initiee par le scenario appelant de SW- Voyages. 

• La methode asynchrone cancel Process est declaree et susceptible d'etre appelee par le serveur 
d'orchestration en cas d'erreur durant le traitement de la methode process. 

• La methode asynchrone compensateProcess est egalement decrite et pourra etre appelee par le 
serveur d'orchestration lorsque le traitement de la methode process se sera bien termine mais 
qu'une erreur aura ete remontee par l'un des participants a la transaction appelante initiee par SW- 
Voyages. 
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Scenario de reservation d'une demande de disponibilites aeriennes 

Le scenario de demande de reservation de disponibilites aeriennes (vous pouvez telecharger le code 
source sur le site www.editions-eyrolles.com) offre les caracteristiques suivantes (fichier {%SW- 
AIR_HOME%}\ReservationService_Book. jbpel) : 

• Lamethode process est asynchrone (metadonnee@ws-conversation:mode async). 

• Lamethode process est toujours associee aune transaction (metadonnee@ws-transacti on: attri- 
bute requi red), comme dans le cas des deux scenarios precedents. Chaque reservation de demande 
de disponibilites aeriennes adressee a SW-Air s'execute dans le contexte transactionnel de son 
client ou declenche une nouvelle transaction metier interne a SW-Air. Le scenario est ici automa- 
tiquement enrole en tant que participant a la transaction initiee par le scenario appelant de SW- 
Voyages. 

• La methode asynchrone cancel Process est declaree et susceptible d'etre appelee par le serveur 
d' orchestration en cas d'erreur durant le traitement de la methode process. 

• La methode asynchrone compensateProcess est egalement decrite et pourra etre appelee par le 
serveur d' orchestration en cas d'erreur remontee par l'un des participants a la transaction appe- 
lante initiee par SW- Voyages. 

Scenario d'annulation de recherche de disponibilites aeriennes 

Le scenario d'annulation de recherche de disponibilites aeriennes (vous pouvez telecharger le code 
source sur le site www.editions-eyrolles.com) presente les particularites qui suivent (fichier {%SW- 
AIRJOME%}\ReservationService_Cancel .jbpel) : 

• Lamethode process est asynchrone (metadonnee@ws-conversation:mode async). 

• Lamethode process est toujours associee aune transaction (metadonnee@ws-transacti on attri- 
bute required), comme dans les trois scenarios precedents. Chaque demande d'annulation de 
recherche de disponibilites aeriennes adressee a SW-Air s'execute dans le contexte transactionnel 
de son client ou declenche une nouvelle transaction metier interne a SW-Air. Le scenario est ici 
automatiquement enrole en tant que participant a la transaction initiee par le scenario appelant de 
SW-Voyages. 

• La methode asynchrone cancel Process est declaree et susceptible d'etre appelee par le serveur 
d' orchestration en cas d'erreur durant le traitement de la methode process. 

• La methode asynchrone compensateProcess est decrite et pourra etre appelee par le serveur 
d' orchestration en cas d'erreur remontee par l'un des participants a la transaction appelante initiee 
par SW-Voyages. 

Descripteurs de deploiement des scenarios de gestion de reservation 

Chacun des quatre scenarios de gestion de reservation est associe a un descripteur de deploiement 
correspondant au format XML. Dans le cas present, ceux-ci sont reduits a leur plus simple expression 
car les scenarios decrits ne font pas appel a des services Web externes. 
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Descripteur de deploiement du scenario de demande de recherche de disponibilites 
aeriennes 

Le descripteur de deploiement du scenario de demande de recherche de disponibilites aeriennes 
(fichier (%SW-AIR_HOME£}\SWAir_Reservation_Search.xml) se presente ainsi : 

|<?xml version="1.0" encoding="UTF-8"?> 
<bpel -scenario src="com.cxdn.samples.swair. ReservationService_Search"> 
</bpel -scenario> 

Descripteur de deploiement du scenario de recuperation des disponibilites aeriennes 

Le descripteur de deploiement du scenario de recuperation des disponibilites aeriennes (fichier 
{%SW-AIR_HOME%}\SWAir_Reservation_Get.xml) est le suivant : 

|<?xml version="1.0" encoding="UTF-8"?> 
<bpel -scenario src="com.cxdn.samples.swair. ReservationService_Get"> 
</bpel -scenario> 

Descripteur de deploiement du scenario de reservation de disponibilites aeriennes 

Le descripteur de deploiement du scenario de reservation d'une demande de disponibilites aeriennes 
(fichier {%SW-AIR_HOME%}\SWAir_Reservation_Book.xml) se presente de la maniere suivante : 

|<?xml version="1.0" encoding="UTF-8"?> 
<bpel -scenario src="com.cxdn.sainples.swair.ReservationService_Book"> 
</bpel -scenario> 

Descripteur de deploiement du scenario d'annulation de recherche de disponibilites 
aeriennes 

Le descripteur de deploiement du scenario d'annulation de recherche de disponibilites aeriennes 
(fichier (%SW-AIR_HOME&}\SWAir_Reservation_Cancel .xml) est code de la maniere qui suit : 

|<?xml version="1.0" encoding="UTF-8"?> 
<bpel -scenario src="com.cxdn.samples.swair. ReservationService_Cancel "> 
</bpel-scenario> 

Classes de support aux scenarios 

Les classes d'implementation des scenarios utilisent, elles aussi, les memes classes de servitude ou de 
support que celles utilisees chapitre 23. Celles-ci sont parfois legerement modifiees pour des raisons 
inherentes au fonctionnement du serveur Collaxa dans sa version actuelle. 

Le paquetage de ces classes devient com. cxdn.samples.swair. reservation. 

Classe ReservationManager.java 

La classe d'implementation du registre local des reservations (fichier {%SW-AIR_HOME%}\Reservation- 
Manager.java) reste inchangee par rapport a la description faite chapitre 23. Cette classe est identique 
a celle de 1' application Web de SW- Voyages (vous pouvez telecharger le code source sur le site 
www.editions-eyrolles.com). 

La classed' interface (fichier {%SW-AIR_HOME%}\ReservationRegistry.java)n'estegalementpas modi- 
fiee. 
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Classe Reservation.java 

La reservation (fichier {ISW-AIR_HOME%}\Reservation. java) conserve les informations relatives a la 
demande de l'utilisateur (caracteristiques du voyage) d'une part, et les disponibilites aeriennes 
communiquees par SW-Air a ses partenaires d' autre part : elle reste quasiment identique a la descrip- 
tion du chapitre 23 (vous pouvez telecharger le code source sur le site www.editions-eyrolles.com). 

La classe est simplement modifiee pour importer les classes de disponibilites qui sont maintenant 
generees par Fenvironnement de developpement de Collaxa (voir ci-apres). La ligne d'importation 

ajoutee est : 

| import com. cxdn. samples .swai r.*; 

Une autre modification est apportee par l'ajout des variables departureAvailabilityld et arrival- 
Avail ability Id utilisees pour permettre la compensation d'une exception dans le scenario d'annu- 
lation de demande de disponibilites et restaurer la reservation a son etat initial (recuperation des 
disponibilites selectionnees par l'application cliente). 

Classe AirAvailability.java 

Les disponibilites aeriennes gerees par SW-Air (classe AirAvailability.java) sont maintenant gene- 
rees automatiquement, a partir du schema XML presente precedemment, lors de la construction et du 
deploiement des scenarios. 

Classe ReservationException.java 

La classe d' exception generique utilisee par l'ensemble des classes de servitude (fichier {%SW- 
AIR_H0ME3!}\ReservationException.java) est simplifiee par rapport a celle utilisee chapitre 23. 
Comme pour la classe equivalente utilisee par l'application Web de SW- Voyages, la variable root- 
Cause de type Throwabl e, ainsi que les methodes associees, sont supprimees (vous pouvez telecharger 
les codes source sur le site www.editions-eyrolles.com). 

Construction et deploiement des scenarios 

L'utilitaire cxant.bat prendle fichier build. xml suivant (fichier (%SW-AIR_HOME%}\build.xml) en para- 
metre : 

<?xml version="1.0"?> 

<project name="ReservationService" default="main" basedir="."> 
<property name="deploy" val ue="true"/> 
<property name="rev" value="l .0"/> 

<property name="out" val ue="${CXHome}/server-default/cl asses "/> 
<target name="main"> 

<schemac input="${basedi r}/Book.xsd" out="${out}"/> 

<schemac input="${basedi r}/Cancel .xsd" out="${out}"/> 

<schemac input="${basedi r}/Get.xsd" out="${out}"/> 

<schemac input="${basedi r}/Search.xsd" out="${out}"/> 

<schemac input="${basedi r} /Avail abil ities.xsd" out="${out}"/> 

<javac srcdi r="${basedi r}" destdir="${out}" includes^"*. java"/> 

<bpel c input="$(basedir}/SWAir_Reservation_Book.xml " 
rev="${rev}" deploy =" ${deploy}"/> 

<bpelc inputs" ${basedir}/SWAir_Reservation_Cancel .xml " 



1014 



Etudes de cas 

ClNQUIEME PARTIE 



rev="$(rev}" deploy="${deploy}"/> 
<bpelc inputs" ${basedi r}/SWAir_Reservation_Get.xml " 

rev="${rev}" deploy="${deploy}"/> 
<bpelc input=" ${basedi r}/SWAir_Reservation_Search.xml " 

rev="${rev}" deploy="${deploy}"/> 
<wsdlc inputs" ${basedi r}/ReservationService_Book. jbpel " out="$(out}"/> 
<wsdlc inputs" ${basedi r}/ReservationService_Cancel .jbpel " out="${out}"/> 
<wsdlc input=" ${basedi r}/ReservationService_Get. jbpel " out="${out}"/> 
<wsdlc inputs" ${basedi r}/ReservationService_Search. jbpel " out="${out}"/> 
</target> 
</project> 

La construction de F application Web est realisee en quatre etapes : 

1. generation, via Futilitaire schemac, de classes de representation Java a partir des quatre schemas 
XML de description des documents d' invocation des scenarios ; 

2. generation, via Futilitaire schemac, des classes de representation Java correspondant au schema 
XML de description des disponibilites aeriennes produites par Fun des scenarios ; 

3. compilation, par le compilateur standard javac, des classes Java de servitude et de support utilisees 
par les scenarios BPEL ; 

4. generation, via Futilitaire bpel c, des classes Java executables a partir des quatre scenarios BPEL. 

Apres construction et deploiement de F application Web, les fichiers .jar, associes aux scenarios 
compiles, sont deployes dans le repertoire {%COLLAXA_HOME%}\server-default\scenarios : 

• bpel_SWAir_Reservation_Book_1.0. jar ; 

• bpel_SWAi r_Reservation_Cancel_l .0. jar ; 

• bpel_SWAi r_Reservation_Get_l .0. jar ; 

• bpel_SWAir_Reservation_Search_l .0. jar. 

La construction de Fapplication est lancee, a partir d'une invite de commandes, et apres s'etre placee 
dans le repertoire {%SW-AIR_H0ME%}, par la commande : 

C:\Collaxa_2.0\cxdk\bin\cxant 



Ordre de construction des scenarios BPEL 

Afin de simplifier le developpement du scenario d'architecture n°4, un certain nombre de classes associees aux 
espaces de noms des partenaires de SW-Voyages, notamment celles qui concernent les structures de donnees 
complexes (disponibilites) ainsi que les documents d'invocation (requetes), auraient du etre explicitement produi- 
tes dans Fapplication Web de SW-Voyages (a partir de la description WSDL compilee des scenarios BPEL des 
partenaires). 

Afin d'alleger cette presentation, cela n'a pas ete realise et les classes de SW-Voyages qui ont besoin d'utiliser ces 
elements referenced directement les classes des partenaires dans leurs propres repertoires. 
Cela n'est bien entendu pas possible dans un cas reel ou les scenarios BPEL des partenaires sont deployes dans 
des environnements disjoints. Cette facilite introduit cependant une contrainte dans I'ordre de construction des 
scenarios BPEL : ceux des partenaires SW-Air, SW-H6tels et SW-Voitures sont independants et peuvent etre 
compiles dans n'importe quel ordre, mais imperativement avant ceux de SW-Voyages. 
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Les tests des scenarios construits et deployes par SW-Air s'effectuent de la meme maniere que pour 
ceux de SW- Voyages (voir section « Test des scenarios BPEL » correspondante). 

lis sont toujours realises par 1' intermediate de la console Collaxa, accessible a partir d'un navigateur 
Internet, via l'URL http://www.sw-voyages.com:9700/collaxa. 

Conclusion 

Les implementations des scenarios d' architecture n os l, 2 et 3 s'appuient sur des technologies et des 
produits completement maitrises et fiables. 

II faut constater empiriquement que les specifications, les technologies et les produits sur lesquels 
nous avons bati la mise en ceuvre du scenario d' architecture n°4 n'ont pas encore atteint le meme 
niveau de maturite. Les infrastructures de fiabilite de l'echange et de gestion de transactions, ainsi 
que les langages de definition de scenarios sont encore dans un etat qui nous permet seulement 
d'implementer des maquettes ou, tout au plus, des prototypes. Mais il faut rappeler que les evolutions 
dans ce domaine sont rapides et que la situation change tres vite a l'heure actuelle. 
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Conclusion 
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Les services Web s'installent pour durer. lis sont le resultat d'une evolution technologique majeure, 
et les bases d'une revolution organisationnelle et economique. Le changement est considerable : les 
services Web vont modifier en profondeur Forganisation du travail et les processus metier des orga- 
nisations (entreprises, administrations, associations). En outre, ils vont changer les pratiques des 
professionnels de l'informatique. 

Ce livre n'a evidemment pas la pretention de decrire et d'analyser ces changements socio-economi- 
ques. Mais, en guise de conclusion, il est interessant et opportun d'esquisser une ebauche de revolu- 
tion des pratiques de travail des informaticiens, que les technologies presentees dans cet ouvrage vont 
sans doute sollicker. 

L'evolution technologique des services Web surgit de la convergence de plusieurs axes de developpe- 
ment (les protocoles Internet, le langage XML, la progression rapide de la puissance des machines et 
de la bande passante) vers un ensemble de technologies qui, n'ayant pas un contenu technique revo- 
lutionnaire a proprement parler, apportent un niveau de standardisation et d'interoperabilite sans 
precedent dans des domaines cle comme l'informatique de gestion. 

A l'heure actuelle, la plupart des industries utilisatrices ne percoivent pas encore les opportunites de 
changement que la disponibilite de cette technologie apporte. Les professionnels de l'informatique 
ont eux aussi des difficultes a percevoir la profondeur des transformations induites par F adoption de 
la technologie des services Web dans le metier de leurs clients et, par consequent, dans leur propre 
metier. Les services Web sont vus souvent comme « encore une autre technologie de middleware », 
un concurrent ou, au mieux, un successeur de CORBA et DCOM, une trouvaille technologique de 
Microsoft et IBM pour relancer la croissance et les investissements, qui apporte sans doute des avan- 
tages mais que Fon peut decider d' adopter ou non au gre de la strategie purement technologique de 
Forganisation. Ce point de vue n'est pas simplement reducteur : il est tout bonnement errone et nous 
allons essayer de montrer pourquoi. 

En fait, au cceur de l'evolution technologique portee par les services Web, il y a la montee en puis- 
sance du concept de service, qui reste une notion encore mal apprehendee. Nous avons vu que les 
concepts de service et d' architecture orientee services sont theoriquement independants des techno- 
logies des services Web. L'exercice qui consiste a concevoir et a decrire un systeme informatique 
etendu sous forme d'une architecture orientee services, independamment de Futilisation ou non des 
technologies des services Web, est sans doute tres utile et benefique, car il correspond a une bonne 
preparation a son evolution en vue de son ouverture. Cependant, il n'est pas realiste de penser que ces 
deux notions vont rester longtemps separables, qu'on pourra mettre en ceuvre des architectures orien- 
tees services au moyen de technologies autres que les services Web. Les technologies des services 
Web (SOAP, WSDL, etc.) vont devenir aussi universelles et omnipresentes que TCP/IP, HTTP, 
HTML, XML. Pour simplifier la discussion, nous allons considerer par la suite qu'il y a identite entre 
architectures orientees services et architectures de services Web et que les technologies des services 
Web sont le moyen d'election pour mettre en ceuvre des architectures orientees services. 

En fait, il est peut-etre interessant de revenir sur la notion de service et de deceler dans cette notion 
les veritables innovations qu'elle comporte, cachees et un peu banalisees sans doute par la surcharge 
semantique du terme « service », dont nous avons fait etat dans F introduction de cet ouvrage. 
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Les services 

Un service n 'est pas un logiciel. Un logiciel est une implementation possible d'un service. Le meme 
service peut etre implemente par des logiciels differents. On peut changer V implementation d'un 
service de facon transparente par rapport a son utilisation. 

Un service n' est pas un processus informatique. Une occurrence d'un service est localisee par un 
port, qui permet d'acceder au processus qui realise le service. Le meme service peut etre realise par 
plusieurs occurrences, localisees par des ports differents, lesquels permettent d'acceder a des processus 
differents qui executent des logiciels differents. 

La notion de service est le produit d'une demarche d' abstraction par rapport au logiciel qui 1' imple- 
mente, au processus qui F execute et au port qui le localise. Pourtant, le service reste un objet tres 
concret et technique. La realisation d'un service passe par des messages echanges, des transitions 
d'etat et des actions que l'application cliente suppose assures de la part de l'application prestataire du 
service. Les caracteristiques fonctionnelles, operationnelles et d' interface d'un service sont consi- 
gnees dans un contrat. Une occurrence d'un service est localisee par unport. 

Ces considerations semblent quelque peu methodologiques, et le lecteur peut se demander ou nous 
voulons en venir. On comprend facilement leur portee pratique lorsque Ton en vient a examiner la 
notion d' architecture : une architecture de services n' est pas une architecture de composants logiciels. 

Les informaticiens ont ete habitues a raisonner depuis plusieurs annees en termes de composants logi- 
ciels, avec des metaphores empruntees a l'industrie du batiment (!), et ont tendance a supposer implici- 
tement l'identite service/composant. Pour beaucoup de concepteurs, un service Web est tout simple- 
ment une autre interface a un objet compile. II faut absolument eviter de tomber dans le piege qui 
consiste a considerer le modele de F architecture orientee services comme une simple extension ou 
evolution du modele traditionnel d' architecture qui repose sur les objets et les composants. Cette appro- 
che conduit a l'application de recettes, relatives a la methodologie de conception, de developpement, de 
deploiement ainsi que de pratiques d' exploitation, propres aux architectures de composants logiciels. Le 
resultat revient souvent a la mise en ceuvre d' architectures fortement couplees, synchrones et avec des 
interactions a faible granularite. 

Un service n 'est pas un composant logiciel. Un service peut etre implemente par un composant logi- 
ciel, mais, de facon generale, un composant peut etre en mesure de pomvoir plusieurs services modu- 
laires. La definition de modularite du service est intuitive, mais il n'est pas inutile de l'expliciter : un 
service est modulaire si, pour l'utiliser, non seulement il n'est pas necessaire de connaitre le logiciel 
qui F implemente (ce qui est dans la definition meme de service), mais il n'est pas necessaire non plus 
de connaitre les autres eventuels services que ce logiciel implemente. Tout ce dont les developpeurs 
et les logiciels ont besoin pour utiliser le service est son contrat, le document WSDL de description 
du service en question. 

C'est la notion de dissemination de services que nous avons evoquee chapitre 4 : une seule applica- 
tion integree (par exemple, un progiciel de gestion integre) peut implementer un ensemble de servi- 
ces modulaires. Le point essentiel est que le client d'un des services issus d'une demarche de disse- 
mination beneficie de la modularite du service sans que la question de la modularite de 
V implementation ne soit meme posee. En informatique, on parle traditionnellement, a ce propos, de 
boite noire et d' 'information hiding. Dans 1' architecture orientee services, le decouplage entre inter- 
face et implementation est pousse aux extremes limites : un service est tout simplement un contrat, et 
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une occurrence d'un service en execution est tout simplement un port (dont Fadresse peut etre 
connue dynamiquement). 

L'agregation de services 

Un service peut etre mis en ceuvre par un seul composant, mais aussi par un logiciel issu de F assem- 
blage de plusieurs composants. L' architecture d' implementation d'un service a Favantage d'offrir la 
mise en ceuvre du modele de 1' architecture par objets et composants logiciels (le plus abouti etant 
celui de FOMG, Model Driven Architecture, accessible sur http://www.omg.org/mda). Mais Fapproche 
service apporte une innovation de taille qui change fondamentalement la perspective sur F architec- 
ture des processus et systemes repartis : un service peut etre implemente par Futilisation recursive 
d'autres services. C'est la notion Aggregation de services, que nous avons introduite chapitre4, et 
qui presente un caractere paradoxal et vertigineux : 

• Elle permet de penser F implementation d'un service par composition d'autres services dont on ne 
connait par F implementation ! 

• Elle permet de penser la realisation du service au moyen de Faeces aux occurrences d'autres 
services dont on ne connaitra la localisation qu'a F execution ! 

Le gain apporte par cette innovation, en termes de productivite de developpement, de facilite de 
deploiement, de qualite d' exploitation et done, globalement, de maitrise des couts est sans commune 
mesure. Son apport ne s'arrete pas la : cette innovation ouvre la voie a la creativite et a F invention de 
nouveaux services a valeur ajoutee, par agregation de services existants. 

La notion d' agregation fait monter le niveau de decouplage entre service et implementation. L imple- 
mentation d'un service par agregation d'autres services est transparente pour le client du service 
agregeant : celui-ci ne connait pas et n'a pas besoin de connaitre Feventuelle sophistication et 
complexite de F implementation du service en ce qui conceme l'agregation d'autres services. Du point 
de vue du client du service agregeant, celui-ci est un service atomique, parfaitement decrit par un 
contrat. Un service atomique peut etre implemente par agregation recursive de services atomiques. 

Comment mettre en ceuvre l'agregation de services ? La aussi, il faut eviter de tomber dans le piege 
qui consiste a penser l'agregation de services comme une extension de la composition d'objets ou 
comme un modele recursif d'appel de procedure distante. L'avantage economique qu' apporte la 
demarche qui consiste a implementer une entite (le service agregeant) par agregation d'autres entites 
(les services agreges) dont on ne connait pas F implementation necessite en echange un modele 
d' agregation plus puissant. 

L'agregation de services se fait par la mise en ceuvre de processus metier, e'est-a-dire d'un ensemble 
des protocoles de cooperation et de coordination des services constituants. II s'agit d'etablir la 
cooperation entre les services agreges, a savoir la division du travail et F echange d' informations 
necessaires pour que les activites de ces services agreges contribuent efficacement a la realisation du 
service agregeant. II est egalement necessaire de coordonner les services agreges, a savoir de 
synchroniser les etapes de leurs activites. L implementation du service agregeant organise la coope- 
ration et coordonne la realisation des services agreges, eventuellement en faisant appel a des services 
specialises de coordination auxquels elle delegue cette tache, comme dans le cas de la gestion des 
transactions et des activites presente chapitre 20. 
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Implementer un service agregeant revient a ecrire un scenario d'un processus metier qui definit la 
cooperation et la coordination des services agreges. 

L'outil de base pour l'agregation de services est done un langage de scenarios de processus metier. 
Parmi ces langages, que nous avons presentes chapitre 21, se degage BPEL (Business Process Execu- 
tion Language), propose initialement par IBM et Microsoft (comme synthese de leurs experiences 
precedentes), que nous avons applique a la mise en ceuvre de l'etude de cas (chapitre 26). BPEL fait 
maintenant l'objet d'un processus de standardisation OASIS (WSBPEL, voir http://www.oasis-open.org/ 
committees/tc_home.php?wg_abbrev=wsbpel). 

Dans BPEL, les primitives de controle du langage designent les modes de combinaison des realisa- 
tions des services agreges (la sequence, l'execution parallele, Falternative, l'execution en boucle, 
etc.), et la definition de conteneurs de donnees permet l'echange d' informations entre les services 
agreges. 

La demarche d' implementation des processus metier par scenarios rappelle celle propre a la mise en 
ceuvre de systemes de workflow (normalises par la Workflow Management Coalition, voir http:// 
www.wfmc.org). La aussi, il faut faire attention a ne pas tomber dans le piege qui consiste a considerer 
un processus metier d'agregation de services comme un workflow plus ou moins evolue. Les processus 
metier d'agregation de services se distinguent sur deux points importants : 

• lis ont un caractere nativement et definitivement recursif et reparti : un service, qui apparait 
comme un service atomique, est mis en ceuvre par un scenario de processus metier d'agregation de 
services repartis qui, a leur tour, sont mis en ceuvre par des processus metier, et ainsi de suite, 
jusqu'aux services « simples », implementes « en dur » par des codes logiciels. 

• La cooperation et la coordination des services, quel que soit le niveau d' agregation, ne peuvent etre 
obtenues qu'au moyen de protocoles de communication par transmission de messages (protocoles 
de conversation), mis en ceuvre entre eux et avec le service agregeant. 

L utilisation poussee de la demarche d'agregation par scenarios conduit a des architectures d' applica- 
tions dans lesquelles des « petits » composants logiciels implemented des services « simples » qui 
sont recursivement agreges via des scenarios. Grace au decouplage entre service et implementation, 
on peut a tout moment remplacer 1' implementation d'un service agrege sans changer le service 
agregeant, et ce a n'importe quel niveau d'agregation dans 1' architecture. 

La cooperation et la coordination avec un service ne peuvent etre obtenues qu'en engageant une 
conversation avec lui. Ainsi, il faut d'abord qu'il comprenne les messages unitaires qu'on lui adresse, 
qui doivent done etre definis dans son interface contractuelle WSDL, mais il est en outre necessaire 
que l'echange de message obeisse a un protocole de conversation, qui est en fait une machine a etats 
finis, et dont le deroulement permet d'etablir en cours d'execution l'avancement de la realisation de 
la prestation du service. 

Dans la conception d'une architecture orientee services, par rapport a des approches plus tradition- 
nelles, 1' attention se concentre done sur l'agregation par scenario de services et la definition de la 
conversation entre eux. Obtenir la cooperation et la coordination de services agreges pour implemen- 
ter un service agregeant demande un niveau plus eleve d' abstraction dans la conception : il faut 
penser en termes de communication avec des entites dont on ne connait pas 1' implementation. 

Penser la relation entre occurrences de services en execution en termes de communication pure 
implique que le concepteur fasse toujours la distinction entre conditions de succes de Facte de 
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communication vehicule par le message (le message est bien forme, il est emis au bon moment par un 
emetteur dont l'identite est authentifiee, qui a les droits et les habilitations pour emettre le message et 
celui-ci parvient effectivement au recepteur) et conditions de satisfaction du meme acte (le recepteur 
effectue les transitions d'etat et les actions definies par le contrat comme consequences de la recep- 
tion d'un acte de communication qui satisfait ses conditions de succes). Nous avons vu que la sepa- 
ration entre succes et satisfaction des actes de communication, propre a toute architecture repartie, est 
a l'origine de la complexite des architectures de services Web car elle demande la gestion des situa- 
tions de defaillance et d'incertitude. 

L agregation de services est done pilotee par un scenario et mise en ceuvre par un protocole de 
conversation generalement multilateral (qui peut aussi tout simplement etre implicitement defini par 
un ensemble de protocoles bilateraux). 

Le scenario et le protocole de conversation, que certains appellent aussi respectivement orchestration 
et choregraphie, n'ont pas le meme statut en termes de visibilite : 

• Le scenario est un objet prive : il definit 1' implementation d'un service. 

• Le protocole de conversation est un objet public : il fait partie, au meme titre de la definition des 
messages unitaires, de la definition de la facon d'interagir avec un service, et done de son interface. 

Cette difference de statut est tres importante et il faut en comprendre toutes les consequences. Celles- 
ci touchent le domaine de la standardisation : en effet, le langage de definition de protocoles de 
conversation (de choregraphies), doit etre, au meme titre que le langage de definition des interactions 
unitaires (WSDL), une technologie standard des services Web, interoperabilite oblige. En revanche, 
il n'est pas necessaire que le langage de scenarios soit normalise comme une technologie des services 
Web (les puristes pourraient meme pretendre qu'il serait malvenu de la standardiser). 

Entendons-nous, la standardisation d'un langage est toujours bienvenue. L'objectif technique d'un 
processus de standardisation d'un langage est la portabilite du code sur differentes plates-formes, au 
moins au niveau source. C'est un objectif tres important, mais etranger au domaine des technolo- 
gies des services Web, qui exigent 1' interoperabilite des differentes implementations, mais sont 
indifferentes a leur portabilite. Par ailleurs, tandis qu'il serait inopportun de devoir se confronter a 
plusieurs standards de choregraphie, il est tout a fait concevable de disposer de plusieurs langages 
d' orchestration (on dispose bien de plusieurs langages de programmation) qui rivalisent en 
puissance et expressivite. 

La premiere version de BPEL (1.0) prevoyait deja la distinction entre scenario prive (orchestration) 
et protocole public (choregraphie). Cette distinction n'etait pas suffisamment bien definie, ce qui a 
entraine la formation d'un groupe de travail au W3C axe sur la standardisation de la choregraphie des 
services Web (http://www.w3.org/2002/ws/chor). Aujourd'hui, la nouvelle version BPEL (1.1) confiee a 
l'OASIS pour standardisation (comite WSBPEL) etablit clairement la distinction entre choregraphie 
publique et orchestration privee. II y a done superposition de deux initiatives de standardisation de la 
choregraphie : l'histoire nous dira si, comme cela serait souhaitable, elles convergeront vers un seul 
standard. 

Le scenario d'un processus metier est prive aussi dans le sens du secret de fabrication. Je concois et 
je propose un service nouveau et novateur, mis en ceuvre par une agregation astucieuse de services 
qui, eux, sont eventuellement accessibles et connus par ailleurs. La valeur ajoutee est dans le scenario 
d' agregation, qui peut soit rester un secret de fabrication, soit donner lieu a une publication dans le 
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cadre d'un brevet en tant que precede de fabrication du service. Cette derniere possibility est tres 
concrete et a donne lieu, aux Etats-Unis, a un engouement, tres critique par ailleurs, pour les brevets 
de processus metier immateriels mis en ceuvre par des programmes informatiques. 

La question de ['infrastructure 

Pour resumer, une architecture orientee services peut etre definie et mise en ceuvre, dans la technologie 
des services Web, par : 

• un ensemble de definitions d'interfaces de services consignees dans des documents WSDL ; 

• un ensemble de protocoles de conversation entre services en suivant le standard W3C/WSCI ou 
OASIS/BPEL ; 

• un ensemble de scenarios de processus metier d' agregation de services, en OASIS/BPEL ou autre 
formalisme, y compris par l'option de base qui consiste a coder le scenario comme un programme 
dans un langage de programmation dote des extensions aptes a l'echange avec les services Web. 

Cela dit, pour que tout cela marche, et que Ton puisse veritablement proceder a la conception et a la 
mise en ceuvre d' architectures sophistiquees par dissemination et agregation de services independants et 
autonomes, d'autres conditions prealables doivent etre verifiees. 

II se pose d'abord une question d' infrastructure. SOAP, WSDL et UDDI constituent une infrastruc- 
ture basique qui permet la mise en ceuvre de services et d' architectures synchrones avec une securite 
point a point, sans exigences poussees de fiabilite, de securite ou de gestion transactionnelle. Cette 
base est en revanche insuffisante pour F automation des processus metier critiques, qui est a terme la 
cible des technologies de services Web. 

Nous avons vu que 1' agregation de services par cooperation et coordination dans des processus 
metier repose exclusivement sur la possibilite de communiquer. La mise en ceuvre de processus 
metiers critiques demande une communication fiable, securisee et transactionnelle et done la disponi- 
bilite des trois technologies d' infrastructure que nous avons analysees dans la quatrieme partie de cet 
ouvrage : 

• F infrastructure de gestion de fiabilite de l'echange ; 

• F infrastructure de gestion de la securite de bout en bout (confidentialite, integrite, authentification, 
autorisation) ; 

• Infrastructure de gestion des transactions. 

Nous avons vu (chapitre 19) que les travaux qui portent sur 1' infrastructure de securite de bout en 
bout avancent sur une feuille de route bien tracee et sont pris en charge par FOASIS (http://www.oasis- 
open.org/committees/tc_home.php?wg_abbrev=wss). Des implementations interoperables de la confidentia- 
lite, de l'integrite et de 1' authentification des messages sont deja disponibles. 

La gestion des transactions est intimement melee a la gestion des processus metier (WS-Transaction 
et WS -Coordination, presentees chapitre 20, sont des specifications ancillaires par rapport a BPEL) 
et semble pouvoir se consolider dans le groupe de travail OASIS/WSBPEL. 

La gestion de la fiabilite de l'echange apparait encore comme la moins bien lotie des technologies 
d'infrastructure. Curieusement, la prise de conscience du role fondamental joue par cette technologie 
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dans des architectures comme celle des services Web, ou tout repose sur la communication entre les 
entites composantes, a ete assez tardive. Nous essay ons dans le chapitre 18 de donner quelques expli- 
cations a ce retard. La fiabilite de l'echange est restee traditionnellement trop liee a la messagerie 
asynchrone, alors que la question de Fasynchronisme est en fait independante de la question de la 
fiabilite de l'echange. La fiabilite, comme Fasynchronisme, peuvent etre mis en ceuvre a differents 
niveaux de communication : au niveau des traitements applicatifs, au niveau de l'echange des messages 
et au niveau des mecanismes de transport. 

Par ailleurs, il est possible que la solution a terme de la fiabilisation des echanges SOAP soit a recher- 
cher non dans l'extension de SOAP, mais dans la fiabilisation des protocoles de transport sous- 
jacents. Aujourd'hui, un groupe de travail OASIS a pris en charge la standardisation de cette infras- 
tructure (http://www. oasis-open. org/committees/tc_home.php ?wg_abbrev=wsrm) . 

En conclusion, les trois chantiers d' infrastructure presentent des etats d'avancement differents, mais 
sont a l'heure actuelle tous identifies et menes par des organismes comme l'OASIS et le W3C, ce qui 
laisse esperer une bonne coherence et une bonne interoperabilite des specifications. 

Par ailleurs, WS-I (http://www.ws-i.org), l'organisme dont l'objectif consiste a garantir F interoperabilite 
des implementations des technologies de services Web, poursuit son travail sur les technologies de base 
(SOAP, WSDL, UDDI) mais s'est attaque egalement aux technologies d' infrastructure, en commencant 
par la securite, plus avancee en termes de definition et de realisation des technologies, avec la creation 
d'un groupe de travail specialise sur le theme (http://www.ws-i.org/docs/20030401wsipr.htm). 



Le contrat de service 

Le concepteur d' architectures de services Web peut done disposer aujourd'hui : 

• des technologies du noyau de base des services Web (SOAP, WSDL, UDDI) stables et aux imple- 
mentations interoperables ; 

• des technologies d' infrastructure (fiabilite de l'echange, securite, transactions), avec une partie des 
fonctions definies et implementees et des processus de standardisation dans un cadre etabli et rela- 
tivement coherent (OASIS) ; 

• un langage de description de scenarios de processus metier et des formalismes de definition de 
protocoles de conversation qui sont eux aussi en developpement, avec des premieres versions 
disponibles et operationnelles. 

Si Fon situe au mois de mars 1998, a la parution de XML-RPC, Facte de naissance des technologies 
de services Web, nous pouvons affirmer que, apres plus de cinq ans, ces technologies ont atteint une 
certaine maturite. Elles permettent aujourd'hui non seulement la rationalisation et le decloisonne- 
ment des systemes d'information etendus des organisations, mais aussi la mise en ceuvre de processus 
metier sur Internet. 

Nous consacrons la derniere section de ce chapitre a quelques conseils pratiques aux architectes et 
concepteurs des services Web. Dans cette section, nous presentons, a partir d'une analyse des 
besoins par rapport a l'objectif de mise en ceuvre d' architectures orientees services pour Fautoma- 
tion des processus metier critiques, ceux qui nous semblent devoir devenir les prochains chantiers 
technologiques. 
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Avant de nous engager dans cette presentation, il est interessant de rappeler le niveau de puissance et 
d'expressivite deja acquis par la notion de service telle qu'elle est prise en charge aujourd'hui par les 
technologies de services Web, a travers deux fonctionnalites populaires chez les inconditionnels de 
1' architecture « objet » : 

• l'heritage multiple d'interfaces de services ; 

• la creation dynamique d'occurrences de services. 

WSDL 1.1 permet deja la reutilisation de documents par importation. II est possible notamment de 
definir un service type (la definition des types des donnees et des types de ports) dans un document 
que Ton peut importer dans d'autres documents qui definissent les liaisons et les adresses des ports. 
WSDL 1.2 (en etat de working draft, voir http://www.w3.org/TR/wsdl12) permet, en plus des mecanismes 
physiques d'inclusion et d'importation de documents (les deux se distinguent par le traitement des 
espaces de noms), le mecanisme logique d'extension d'interfaces par heritage multiple des types de 
ports (interfaces abstraites). Ce mecanisme permet la composition des interfaces et est particuliere- 
ment interessant pour etendre, avec de nouvelles interfaces a des fonctions a valeur ajoutee, un 
service type ayant une definition standard par ailleurs. 

La creation dynamique d'occurrences de services est deja possible aujourd'hui. L'idee est de s'appro- 
cher de la pratique, courante en conception orientee objets, qui consiste a creer dynamiquement des 
occurrences de classes. Par exemple, lors de l'interaction avec un service bancaire, une occurrence 
ephemere du service type « Compte bancaire », decrit par un document WSDL approprie, correspon- 
dant a mon compte bancaire, est creee a la volee, dotee d'un port dynamiquement attribue, pour une 
duree de vie correspondant a la duree de la « session » d' interaction avec cette occurrence. 

Evidemment, ce type d' architecture, comme les architectures a objets distribues similaires, necessite 
la prise en charge attentive du cycle de vie de 1' occurrence ephemere du service, pour eviter que 
l'architecture soit polluee a l'execution d'occuiTences fantomes residuelles. Ce style de conception 
tirera avantage des mecanismes de virtualisation et de gestion de cycle de vie des architectures en 
grille d'ordinateurs, via la mise en ceuvre du service ephemere par un grid service, tel qu'il est defini 
dans l'Open Grid Services Infrastructure (http://www.gridforum.org/ogsi-wg). 

Nous avons presente dans la premiere partie de cet ouvrage le concept de contrat de service, a la base 
de l'architecture orientee services. Le contrat definit et decrit le service de facon independante de son 
implementation. Lorsque nous disons qu'un document WSDL (Web Services Description Language) 
decrit un service, nous faisons en fait un raccourci : en realite, un document WSDL decrit V interface 
d'un service (et aussi une partie de son implementation, c'est-a-dire F implementation de l'interface). 
Ce que le service fait, au-dela des echanges de messages, et la facon dont il le fait n'est pas formalise 
dans le document WSDL. 

En fait, deux elements essentiels manquent a l'appel : 

• la description des fonctions du service ; 

• la description des caracteristiques operationnelles (d'une occurrence) du service. 

En Fetat actuel de choses, aucune technologie de description formelle des fonctions et des caracte- 
ristiques operationnelles d'un service n'est disponible. II reste deux moyens d'approche pour Futili- 
sateur du service : 

• la documentation accessible ; 

• Faeces au code source d'une des implementations du service. 
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Les limites de la premiere approche sont bien connues. Dans la pratique, la lecture de la documenta- 
tion s'accompagne souvent de sessions de formation et d'echanges informels avec les concepteurs et 
les experts. Cela est viable au cas par cas, a l'interieur de Forganisation et dans les partenariats bien 
etablis, mais le probleme de l'acces au bon niveau d'information pour le plus grand nombre d'utilisa- 
teurs reste ouvert. Dans un monde de services Web, il est egalement question de recherche et d' inter- 
pretation automatique de ce type d'information par des programmes d' indexation et de generation de 
proxies evolues. 

La deuxieme approche est viable pour les services internes a Forganisation, mais elle est interdite 
par definition lorsqu'il s'agit d'utiliser un service externe. Soit dit en passant, cette interdiction 
objective va forcer le changement d'habitudes bien ancrees comme la pratique de reutilisation du 
logiciel en mode « boite transparente », qui consiste, pour le fournisseur, a definir insuffisamment, 
voire pas du tout, les interfaces car le code source est accessible et, pour l'utilisateur, a inspecter 
systematiquement le code source pour comprendre comment utiliser le logiciel. 

La definition formelle des fonctions et des caracteristiques operationnelles d'un service fait aussi 
office de specification formelle du logiciel qui l'implemente. Les methodes formelles de specification 
sont (partiellement) utilisees dans des domaines sensibles (aeronautique, espace, defense), mais 
n'ont pas cours dans d'autres secteurs cibles privilegies des architectures de services Web, comme 
l'informatique de gestion ou les application B2B, sauf quelques exceptions notables, comme le 
domaine relatif au langage objet Eiffel developpe par Bertrand Meyer (voir Design by Contract sur 
http://archive.eiffel.com/doc/manuals/technology/contract/page.html). 

Les methodes et techniques de specification formelle, comme Design by Contract, reposent sur la 
definition formelle des preconditions et des postconditions d'un traitement et sont applicables sur des 
microarchitectures de programme. Les appliquer aux services, pour obtenir une definition formelle 
de leurs fonctions qui soit utilisable par les implementeurs aussi bien que par les utilisateurs, semble 
une voie prometteuse, mais il est certain que l'essentiel du travail reste a accomplir. 

Le seul programme d'envergure qui avance dans ce domaine est celui mene par l'activite Semantic 
Web du W3C (voir http://www.w3.org/2001/sw), avec la formalisation d'un langage de description 
d'« ontologies » (OWL Web Ontology Language, voir http://www.w3.org/TR/owl-features) pour caracteri- 
ser les ressources accessibles sur le Web. Par ailleurs, les industriels les plus actifs dans les technolo- 
gies de services Web reprochent au W3C de consacrer trop d'energie a cette activite, qui est parrainee 
directement par le directeur du W3C, Tim Berners-Lee. La definition d'un langage qui permet de 
rediger des « ontologies », propres aux differents secteurs economiques, comprehensibles par 
programme, n'est qu'un premier pas, car ensuite il faudra concevoir et standardiser ces fameuses 
ontologies, avant de pouvoir les utiliser pour decrire formellement les fonctions des services Web. 

II faut done s'accommoder a l'idee que la description fonctionnelle des services va rester dans le 
domaine de l'informel pendant un certain temps. Cette situation entrainera sans doute la standardisa- 
tion d'un certain nombre de services metier de base : la semantique d'un service metier standardise et 
largement utilise est facilement comprehensible meme si elle n'est pas formellement definie. Un 
travail important dans ce domaine est celui conduit par l'OASIS autour d'UBL (Universal Business 
Language, voir http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl). 

Si la definition formelle des fonctions du service n'est pas pour aujourd'hui, il est en revanche possi- 
ble d'avancer rapidement dans le domaine de la description des caracteristiques operationnelles du 

service. 
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II faut eviter de tomber dans le piege qui consiste a considerer que la distinction entre contrat et 
implementation du service correspond a la distinction traditionnelle entre analyse fonctionnelle et 
implementation, entre le metier et la technique. Le paradoxe que represente 1' implementation d'un 
service au moyen d'autres services dont on ne connait pas 1' implementation n'est maitrisable sur 
grande echelle que si les services utilises sont dotes, en plus des specifications fonctionnelles et 
des specifications d' interface (ces dernieres etant les seules specifications formelles a la date 
d'aujourd'hui), de specifications operationnelles. Ces specifications operationnelles caracterisent 
le comportement operationnel d'un service d'un point de vue technique mais de facon indepen- 
dante de son implementation et de sa localisation et sont done d'une aide precieuse pour construire 
une architecture d'agregation performante. 

C'est la qu'entre en jeu la notion de qualite de service, que nous avons esquissee chapitre 3. Penser la 
qualite de service n'est rien d' autre que formaliser des caracteristiques operationnelles (d'une occur- 
rence) d'un service independamment de son implementation et de sa localisation. C'est une revolu- 
tion culturelle, dans des mondes, par exemple celui de l'informatique de gestion, qui considerent 
souvent les caracteristiques operationnelles d'un systeme en execution non comme des specifications 
a respecter par son implementation, mais comme des contraintes inevitablement produites par les 
aleas de sa mise en ceuvre. 

Les habitudes disparaissent difficilement mais aujourd'hui on semble prendre le probleme a l'envers 
et considerer le dimensionnement, la precision, la performance, l'accessibilite, la fiabilite, la disponi- 
bilite, la continuite d'un service, comme des proprietes que Ton mesure apres, et done comme un 
probleme de service management, de surveillance et d' administration, d'oii l'essor recent d'une offre 
variee d'outils accompagnee par la formation de l'immanquable comite technique OASIS (Web Servi- 
ces Distributed Management TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm), qui, 
pour l'instant, n'a pas encore produit de documents exploitables. 

L'idee de gerer une occurrence de service comme une ressource est interessante, mais le plus impor- 
tant, pour que cette occurrence puisse etre impliquee aisement dans une architecture orientee servi- 
ces, est de definir formellement et de facon quantifiee ses caracteristiques operationnelles. Par 
ailleurs, certaines de ces caracteristiques peuvent faire l'objet d'une negociation a l'execution. A 
partir de l'expression formelle, en termes d'engagement, des caracteristiques operationnelles du 
service, il sera possible de suivre par des outils d' administration et de surveillance la tenue de ces 
engagements. 

Une partie des caracteristiques operationnelles du service, comme les niveaux de fiabilite de 
l'echange, de securite et de gestion des transactions, sont exprimees par les formalismes developpes 
dans le cadre de ces technologies d'infrastructure. II reste que l'expression des autres caracteristi- 
ques, comme la performance, la disponibilite, etc., n'est pas formalisee aujourd'hui. Cela peut aller, 
par exemple, de l'engagement de disponibilite d'un service a des proprietes toutes simples, mais dont 
l'expression est tres utile, comme le delai maximal d'attente (timeout) que Ton s'autorise dans une 
interaction. La specification WS-Policy (http://www.verisign.com/wss/WS-Policy.pdf) definit un cadre gene- 
ral et un formalisme pour la definition de policies, regies qui peuvent etre interpreters comme des 
engagements applicables, d' ailleurs, au prestataire comme au client du service. WS-Policy peut 
constituer la base d'une specification du niveau de qualite de service qui peut etre soit integree 
comme extension dans un document WSDL, soit integree dans l'en-tete d'un message SOAP et faire 
l'objet d'une negociation a l'execution. 
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La pratique 

Le point d'accrochage des technologies des services Web, pour les organisations qui n'ont pas encore 
franchi le pas, reside dans F urbanisation du systeme d' information. L' occasion la plus favorable est 
le besoin de reutilisation d'une application d'entreprise (un systeme patrimonial, un progiciel de 
gestion integre, une application client/serveur, une application Web) hors de son perimetre usuel 
d'utilisation. L'enjeu est done de batir une interface de service Web pour cette application, sans 
changer ni ses fonctions, ni son implementation. 

Dans ce cas, 1' application de la demarche de dissemination est tres importante. Quelles que soient la 
taille et la complexite de 1' application, il convient de definir les services les plus simples et les plus 
modulaires. Dans la conduite du projet, il faut suivre une approche de developpement souple, avec 
des petites equipes, et donner enormement d' importance au test, qui doit etre planifie et outille (en 
termes d'environnement) au debut du projet. Sauf si le besoin est clairement exprime, il faut eviter la 
tentation de faire evoluer les fonctions ou de modifier 1' implementation de 1' application. 

II est aussi conseille de developper l'application cliente du nouveau service, si Foccasion se presente, 
comme un service Web, meme si e'est une application directement exploitee par des utilisateurs. Si 
possible, cette application doit etre developpee en architecture d'agregation de services, avec un 
scenario BPEL qui pilote Faeces a des services de base, les « internes » et ceux implemented par 
l'application patrimoniale. L'interface utilisateur doit etre developpee comme une application sur le 
poste de travail qui permet d'acceder a un service Web : le chapitre 16 presente un ensemble non 
exhaustif de technologies sur le poste de travail (IE, Mozilla, Word XP, Excel XP, Flash) qui peuvent 
etre utilisees pour developper une interface homme/machine evoluee a un service Web. Dans cette 
mouvance, il est tout a fait envisageable d'implementer Fagregation de plusieurs services Web 
directement par la programmation du poste de travail. 

Ces techniques, ainsi que d'autres presentees chapitre 13, peuvent egalement etre utilisees pour deve- 
lopper une interface homme/machine basique mais complete aux services Web issus de l'application 
patrimoniale. Cette interface est non seulement tres utile dans les activites de test, mais aussi en 
exploitation, pour intervenir manuellement dans des situations d'erreur ou de defaillance de l'appli- 
cation cliente (pour passer, par exemple, des transactions compensatoires). Ce developpement est 
evidemment superflu si l'application patrimoniale en question est deja dotee d'une interface homme/ 
machine qui permet d'effectuer ces merries operations. 

A Foccasion de cette premiere experience, il faut saisir Foccasion de proceder a une analyse rapide 
du systeme d' information. Par ailleurs, Fannuaire UDDI prive, que Fon a mis en route a Foccasion 
de cette experience (et nous conseillons de le faire meme si, en pratique, une architecture quasi stati- 
que ferait F affaire), peut etre utilise comme annuaire des applications d'entreprise dans leur etat 
actuel (une application n'a pas besoin de devenir un service Web pour etre enregistree dans un 
annuaire UDDI !). L' annuaire UDDI prive peut devenir un excellent outil de support du recensement 
des applications qui constituent le systeme d'information. 

A cette analyse rapide, il faut faire suivre la conception d'une architecture orientee services, au meme 
niveau de granularite, pour le systeme d'information de F organisation. Cette architecture devient un 
element essentiel de F evolution du plan directeur. L' architecture orientee services et Fannuaire des 
applications doivent etre mis a jour regulierement en enregistrant les changements. 



Conclusion generale 
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Le travail de construction d' interfaces de services Web pour les applications patrimoniales peut 
suivre une logique opportuniste (au fur et a mesure des besoins de reutilisation des applications exis- 
tantes) ou volontariste, selon la strategie de F organisation. Dans tous les cas, il faut ne pas avoir peur 
de l'heterogeneite et suivre un modele de « federation » des logiciels. Avec l'introduction des servi- 
ces Web dans le systeme d' information, on sort de la tendance, propre aux annees quatre-vingt-dix, 
des grands, longs et couteux projets de progiciels integres. Les technologies des services Web vont 
probablement donner un coup de fouet au marche des composants, avec des composants dotes 
d' interfaces de services Web. Par ailleurs, dans des situations appropriees, le marche des composants 
peut devenir un pur marche de services : ce qui est commercialise n'est pas un logiciel mais Faeces a 
un port. 

Lorsque le portefeuille de services Web de l'entreprise, enregistre sur Fannuaire UDDI prive qui est 
tenu a jour soigneusement, devient fourni, il faut introduire deux problematiques correlees : 

• La question de la mise en ceuvre par agregation de nouveaux services Web et de nouvelles appli- 
cations a valeur ajoutee pour Forganisation (il faut rappeler que toute nouvelle application pour 
Futilisateur final peut etre en fait un nouveau service Web, si Fon suit la discipline d'implementer 
F interface homme/machine comme un client de service Web sur le poste de travail). 

• La publication, a Fexterieur de l'entreprise comme un service Web externe, soit d'un service Web 
interne deja existant, qui pourrait interesser les partenaires de Forganisation, soit d'un nouveau 
service, mis en ceuvre par agregation de services internes existants (ainsi qu'eventuellement 
d'autres services externes). Evidemment, cette publication ne peut survenir que lorsque les consi- 
gnes de securite sont operationnelles, ce qui peut correspondre a une action specifique de mise en 
ceuvre de fonctions de securite. 

Cette etape est decisive, car, a partir de la, les services Web ne sont plus seulement une technologie 
informatique utile pour Furbanisation et le decloisonnement du systeme d' information, mais deviennent 
le vecteur de changement des processus metier qui se deroulent a Finterieur de Forganisation et entre 
Forganisation et ses partenaires, ainsi que le support d'une nouvelle offre de services. Cette transforma- 
tion induit le fait que le pouvoir de planification et de decision du developpement des services Web 
passe alors de la direction informatique aux specialistes metier et a la direction generale. 
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Description Description Description 


Accreditation 


Revendication qui porte sur I'identite d'une entite (authentification) impli- 
queedans un echange. 


Credential 


Activite 


Traitement decompose en un arbre de taches, dont I'execution est prise 
en charge par plusieurs agents logiciels repartis participant a un proces- 
sus metier. L'execution, reussie ou non, de chaque tache amene le pro- 
cessus dans un etat (intermediaire ou final) visible de I'exterieur. Une 
activite met generalement en oeuvre un processus metier « long ». Une 
activite est aussi appelee « transaction longue ». 


Activity 


Agent logiciel 


Programme autonome qui est capable d'agir dans un environnement et 
dont le comportement tend a satisfaire des objectifs, en tenant compte 
des evenements et des communications qu'il resoit, a partir des informa- 
tions, regies et ressources dont il dispose. 


Software agent 


Agregation de services 


Demarche de mise en oeuvre (de la definition au deploiement) d'un ser- 
vice dont la prestation est le resultat de I'utilisation d'un ou plusieurs 
autres services. 


Aggregation 


Annuaire de services 


Service qui gere une base d'information constitute d'un repertoire de 
fournisseurs de services, d'un referentiel d'offres (contrats) de service et 
d'un carnet d'adresses des points d'acces aux services. 


Registry 


Annulation 
(de transaction) 


Action d'invalidation de la sequence de traitements representee par une 
transaction, suite a une interruption. Les changements d'etats produits 
par ces traitements sont annules. 


Rollback 


Application orientee service 


Application pouvant participer a une architecture orientee services. Une 
application orientee service peut interpreter plusieurs roles de presta- 
taire ou de client de plusieurs services. 


Service Oriented 
Application 
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Architecture a configuration 
dynamique 


Par opposition a une architecture a configuration statique, les elements 
constitutifs (agents logiciels repartis) d'une architecture a configuration 
dynamique se « decouvrent » et instrumentent des relations de service a 
I'execution. Dans une forme degradee, ces elements sont connus au 
moment du deploiement de I'architecture, mais sont capables de negocier 
les parametres et les conditions de fonctionnement en debut d'execution. 


Dynamic architecture 


Architecture orientee 
services (AOS) 


Architecture constitute d'un ensemble eventuellement dynamique 
d'applications logicielles reparties jouant les roles de prestataires et 
clients de services. Toute application participante d'une AOS est une 
application orientee service. 


Services Oriented 
Architecture (SOA) 


Assertion 


Enonce de forme sujet/predicat qui fait office de declaration d'une pro- 
priete du sujet. 


Assertion 


Authentification 


L'authentification d'un document (ou d'un message) est la preuve de 
I'identite du producteur du document. En general, l'authentification d'une 
partie (acteur humain ou agent logiciel) est la preuve de son identite. 
L'authentification est generalement obtenue par une signature (par cle 
privee), qui est verifiable par une cle publique. Elle peut etre aussi obte- 
nue par le partage d'un secret. 


Authentication 


Autorite de certification 


Entite capable d'emettre des certificats a laquelle on accorde un degre 
de confiance. 


Certification authority 


Certificat 


Document qui atteste de I'identite d'une entite (acteur humain, agent 
logiciel...) et contient, entre autre, sa cle publique. II est emis et signe par 
une autorite de certification. 


Certificate 


Chiffrement 


Procedure qui consiste a encoder une chaine d'octets (dite en clair) dans 
une autre chaine (dite chiffree), qui peut etre decodee par une procedure 
de dechiffrement correlee. La procedure de chiffrement utilise generale- 
ment des algorithmes bases sur une cle (symetrique ou publique). 


Encryption 


Choregraphie 

(de processus metier) 


Description du protocole public d'echange de messages et des enchai- 
nements de ces echanges entre applications participantes au processus 

metier. 


Choreography 


Codage 
(style de) 


Un style de codage de donnees utilise dans un message est constitue d'un 
format de representation des donnees et des procedures de traduction du 
format des donnees dans la memoire vers la representation codee (proce- 
dure d'encodage) et, a I'inverse, de la representation codee vers la struc- 
ture en memoire (procedure de decodage). La representation codee 
comprend un format pour les donnees atomiques et pour les structures de 
donnees, eventuellement en graphe (partagees et circulaires). 


Encoding style 


Compensation 
(transaction compensatoire) 


Une transaction compensatoire est une transaction capable de defaire 
une partie des changements d'etat produits par la confirmation d'une 
autre transaction. La mise en ceuvre de transactions compensatoires est 
necessaire pour diminuer les consequences des erreurs humaines. Elles 
sont aussi utilisees dans la gestion asynchrone de transactions reparties, 
lorsqu'il faut interrompre une transaction globale (composee de plusieurs 
transactions reparties) et revenir a un etat le plus proche de I'etat initial. 
Dans ce cas, les transactions compensatoires, associees aux transactions 
reparties confirmees au moment de I'interruption, sont executees. 


Compensation 
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Description Description Description 


Condense 


Document obtenu a partir d'un autre document (ou d'un message) par 
I'application d'une fonction dite de hachage. Le condense est generalement 
utilise pour prouver I'integrite d'un document et construire la signature. 


Digest 


Confidentiality 


La confidentiality (d'une partie) d'un document (ou d'un message) est la 
garantie qu'une partie indelicate (acteur humain ou agent logiciel) ne 
peut pas acceder au contenu du document. La confidentialite est gene- 
ralement obtenue par chiffrement du document. 


Confidentiality 


Confirmation 
(de transaction) 


Action de validation de la sequence de traitements representee par une 
transaction. Les changements d'etats produits par ces traitements 
deviennent durables. 


Commit 


Connexion 


Une connexion (logique) est etablie entre deux systemes lorsque cha- 
cun d'eux opere un controle de transmission des donnees. Un protocole 
ou un service oriente connexion est synonyme de transmission fiable. 
(Par exemple :TCP est un protocole oriente connexion) 


Connection 


Contrat de service 


Document de description et de formalisation d'une relation de service, 
presentant les engagements entre un prestataire de service et ses 
clients, et eventuellement des tiers ou intermediates. Le contrat de ser- 
vice formalise les fonctions, I'interface et le niveau de qualite de service. 
II decrit I'interface du service au niveau fonctionnel et implementation. 


Service agreement 


Conversation 


Une conversation implique au minimum deux agents logiciels. Elle con- 
sists en un echange bidirectionnel de messages, en utilisant un format 
comprehensible par toutes les parties, selon des regies pre-etablies 
(protocole de conversation) ou non (conversation libre). 


Conversation 


Correlation 


Relation entre messages echanges dans le cadre d'un protocole . Dans 
le cas le plus simple, relation entre le message de requete et celui de 
reponse dans le style d'echange requete/reponse. La correlation entre 
requete et reponse peut etre implicite lorsqu'elle est entretenue par un 
protocole synchrone. Elle est explicite lorsqu'elle est mise en ceuvre par 
I'inscription dans le message de son propre identifiant et de I'identifiant 
du message correle. 


Correlation 


Cycle de mise en ceuvre 
d'une relation de service 


Decrit les differentes etapes qui jalonnent la vie d'une relation de service 
entre partenaires. Cette relation debute par une phase initiale d'informa- 
tion mutuelle, poursuivie par une etape de negociation qui s'acheve nor- 
malement par la signature du contrat de service. La relation entre 
ensuite dans la phase d'instrumentation du contrat et se termine par 
I'etape d'execution du contrat. Pendant I'execution, les partenaires peu- 
vent demarrer un nouveau cycle, et ainsi de suite (cycle a spirale). 


Service relationship 
implementation cycle 


Dechiffrement 


Procedure inverse du chiffrement, qui consiste a appliquer un algor ithme 
(de dechiffrement) a une chaine d'octets chiffree pour obtenir la chaine 
en clair correspondante. Elle utilise le meme algorithme que la proce- 
dure de chiffrement, base sur une cle (symetrique ou privee). 


Decryption 


Decodage 
(procedure de) 


Procedure inverse de I'encodage. Constitution d'une structure de don- 
nees en memoire a partir d'une representation codee dans un message. 
II comprend le decodage des formats des donnees atomiques et la cons- 
titution de structures de donnees en graphe a partir de la sequence 
d'octets du message (de-serialisation). 


Encoding 
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Decouverte 


Action de recherche et de localisation de ('implementation d'un service 
selon des criteres et des methodes de recherche plus ou moins 
sophistiques. La decouverte d'un service peut etre menee a partir de 
simples criteres techniques (adressesconnues...), et aller jusqu'a ('uti- 
lisation de criteres metier via un annuaire de services (interfaces abs- 
traites de services...). 


Discovery 


Degre de couplage 
d'une architecture repartie 


Niveau de dependance fonctionnelle, technologique et operationnelle 
entre les elements constitutifs d'une architecture repartie. Ce niveau 
evolue dans un continuum qui varie d'une architecture fortement cou- 
plee (exemple de couplage operationnel : I'architecture n'est plus opera- 
tionnelle des lors que Tun des constituants est hors service) afaiblement 
couplee (I'architecture est toujours operationnelle, eventuellement en 
mode degrade, meme lorsque un ou plusieurs constituants ne sont plus 
en service). 


Coupling degree 


Delai d'attente maximum 


Lorsqu'une application ou un systeme est dans I'attente d'un evene- 
ment, le delai d'attente maximal indique la duree d'attente que I'applica- 
tion s'autorise avant de reprendre le controle de I'execution sans que 
I'evenement ne se soit produit. 


Timeout 


Deserialisation 


Procedure inverse de la serialisation. Procedure de constitution d'une 
structure de donnees complexe en graphe a partir d'une sequence 
d'octets (de bits). 


Deserialization 


Dissemination de services 


Demarche de mise en ceuvre (de la definition au deploiement) de plu- 
sieurs services modulaires a partir d'une application integree. 


Dissemination 


Echange fiable 


Une infrastructure d'echange totalement fiable permet la transmission 
de chaque message exactement une fois, dans la sequence d'emission, 
en assurant son integrite ou retourne un compte-rendu credible de 
I'impossibilite de la transmission. Des niveaux moins contraignants de 
fiabilite permettent la transmission exactement une fois mais eventuelle- 
ment hors sequence, au moins une fois et au plus une fois. 


Reliable messaging 


Encodage 
(procedure d') 


Constitution d'une representation codee dans un message a partir d'une 
structure de donnees en memoire. La procedure comprend la mise en 
oeuvre d'un format de codage pour chaque type de donnee atomique 
(entier, flottant. ..) et la production d'une sequence d'octets en represen- 
tation de structures de donnees en graphe (serialisation). Voir aussi 
decodage. 


Decoding 


Framework 


Le sens le plus frequemment utilise designe une structure (un cadre) dans 
laquelle une application informatique est congue, developpee et executee. 
Cette structure impose generalement un modele (de conception, de deve- 
loppement, de deploiement, d'execution) cense simplifier, assurer la cohe- 
rence et permettre une industrialisation poussee de la gestion du cycle de 
vie d'un logiciel (exemple : les frameworks J2EE et .NET). 


Framework 


Gestion 

de processus metier 


Ensemble des operations de mise en oeuvre, deploiement, exploitation, 
pilotage et suivi de processus metier informatises. 


Business Process 
Management 


Hachage 
(fonction de) 




Fonction qui permet d'obtenir le condense d'un document. La fonction 
possede comme propriete qu'une modification, meme infime, du docu- 
ment d'origine se traduit par une modification appreciable du condense. 


Hashing 
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Description Description Description 


Identite 


Lidentite d'une entite (un utilisateur, une application, une machine...) est 
un ensemble d'attributs (qui sont censes decrire I'entite en question) 
dote d'un identifiant. 


Identity 


Infrastructure 
a cle publique 


Infrastructure qui permet d'authentifier des autorit.es de certification, a 
partir d'une racine de certification, a savoir d'une autorite de certification 
qui est authentifiee a priori. Cette infrastructure est fondee sur I'adoption 
de procedures de signature/verification sur la base d'algorithmes a cles 
asymetriques (cle publique/cle privee). 


Public Key 
Infrastructure (PKI) 


Integrity 


L'integrite d'un document (ou d'un message) est la garantie que celui- 
ci n'est pas modifie, transforme ou corrompu, de facon accidentelle ou 
intentionnelle, sans que le consommateur du document ne s'en aper- 
coive. L'integrite est obtenue par differents moyens et notamment par 
I'association du document avec son condense signe par le producteur 
du document. 


Integrity 


Interface 


L'ensemble des actes de communication echanges entre deux appli- 
cations reparties jouant les roles de client et prestataire d'une relation 
de service. On distingue I'interface abstraite, qui decrit l'ensemble des 
messages que les applications s'echangent independamment des 
details techniques de mise en ceuvre de la communication, de I'inter- 
face concrete qui, a I'inverse, precise ces details. 


Interface 


Interface de programmation 
d'application (API) 


Une API designe un jeu standard de procedures (programmation pro- 
cedural) ou de methodes (programmation orientee objets) concues 
pour permettre I'acces aux fonctions d'une application particuliere (de 
« s'interfacer avec ») et normaliser ainsi le dialogue entre appli- 
cations. 


Application 
programming 
interface (API) 


Interoperability 


Propriete des interfaces d'echange (format de messages, protocoles 
d'echange...) de deux ou plusieurs agents logiciels mis en ceuvre sur 
des bases technologiques et architecturales differentes, qui leur per- 
met de s'echanger des donnees. 


Interoperability 


Jeton de securite 


Objet numerique contenu dans un message qui rassemble des infor- 
mations de securite a destination du recepteur du message, (relati- 
ves, par exemple, a la signature et/ou au chiffrement de parties du 
message). Un jeton de securite peut contenir des revendications de la 
part de I'emetteur du message et en general des assertions. 


Security token 


Liaison 


Ensemble constitue d'une convention de codage du contenu des mes- 
sages et des consignes d'utilisation d'un protocole de transport, qui 
s'applique a une interface abstraite. La liaison indique comment faire 
fonctionner une interface sur une infrastructure d'echange concrete. 


Binding 


Message 


Unite elementaire d'information echangee entre deux applications 
clientes et prestataire d'une relation de service. Chaque message est 
decrit dans I'interface abstraite d'un service. 


Message 


Metadonnee 


Donnee qui decrit une autre donnee a laquelle elle est associee (pre- 
fixe grec meta : la succession, apres, au-dela). 


Metadata 


Non-repudiation 


La non-repudiation d'une action (par exemple, I'envoi d'un message) 
est la garantie que, une fois Taction accomplie, I'agent, ou une autre 
partie, ne soit pas en mesure de pretendre qu'elle n'a jamais ete 
effectuee. La non-repudiation d'un echange est generalement obte- 
nue par I'authentification et la journalisation de I'echange authentifie. 


Non repudiation 
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Orchestration 

(de processus metier) 


Organisation des traitements et des echanges de messages du point 
de vue d'une application participante au processus metier (processus 
executable). 


Orchestration 


Processus metier 


Activite issue de la collaboration de plusieurs acteurs humains et agents 
logiciels suivant un scenario impose. Cette activite implique generale- 
ment la cooperation des acteurs et agents (chacun accomplit des taches 
pour atteindre un but commun), la communication (les acteurs et agents 
s'echangent des informations) et la coordination, qui est generalement 
etablie dans le scenario mais peut aussi faire I'objet de decisions en 
temps reel prises par des acteurs ou agents jouant les roles de coordon- 
nateurs. Dans une AOS, la cooperation prend la forme d'echange de 
prestations de services et la communication passe par des interfaces de 
services. 


Business process 


Proxy 


Prefixe generique anglais qui signifie « procuration », « representant 
de ». Dans le domaine Internet, un serveur proxy (ou proxy-serveur) 
designe une machine qui execute des requetes pour le compte d'autres 
machines (utilisation de plus en plus courante : voir aussi d'autres ter- 
mes techniques tels que proxy-objet, proxy-service... ou fonctionnels 
tels que proxy-dossier, proxy-contrat...). Le proxy d'un service Web est 
un code qui le « represents » en local chez le client du service et qui se 
charge de la communication avec le service. 


Proxy 


Qualite de service 


Ensemble de proprietes d'un service (performance, fiabilite, disponibi- 
lite, continuity. ..) qui determinent les caracteristiques operationnelles 
(non fonctionnelles) de la prestation. 


Quality of Service 


Relation de service 


Relation etablie entre deux applications qui interpreted les roles de 
client et de prestataire de service. 




Revendication 


Assertion sur une entite (acteur humain ou agent logiciel), emise par 
I'entite elle-meme ou par une autre entite a qui on fait confiance. La 
preuve de certaines revendications peut etre exigee par le destinataire 
du message comme condition d'acceptation du message lui-meme. 


Claim 


Serialisation 


Procedure de constitution d'une sequence d'octets (de bits) en represen- 
tation d'une structure de donnee en graphe. Voir aussi deserialisation. 


Serialization 


Service Web 


Agent logiciel fournissant une prestation de service dont les termes sont 
decrits par un contrat de service au format WSDL. L'echange de messa- 
ges entre le service Web prestataire et le client est formalise dans le 
document WSDL (interface) et mis en ceuvre sur des protocoles comme 
SOAP, HTTP GET/POST et MIME (WSDL et SOAP sont des recomman- 
dations du W3C, HTTP et MIME constituent des RFC de I'lETF). 


Web Service 


Session 


Maintien de l'echange entre deux systemes au-dela de la duree d'un 
acte de communication, generalement par le biais d'un contexte de ses- 
sion, persistant ou non. La plupart du temps, la fin d'une session est 
declenchee soit par une action volontaire, soit par I'expiration d'un delai 
d'attente (timeout). 


Session 


Signature 


Procedure qui consiste a associer a (une partie d') un document ou mes- 
sage un autre document (la signature) qui atteste de I'identite du produc- 
teur du document. La signature est generalement obtenue par 
chiffrement du condense d'un document avec la cle privee (du signa- 
ture). Dans ce cas, la verification de la signature consiste a la dechiffrer 
a I'aide de la cle publique du signataire. 


Signature 
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Transaction 


Ensemble de traitements, pris en charge eventuellement par plusieurs 
agents (transaction repartie), qui doit etre execute comme un tout (tout 
ou rien), de fason isolee par rapport aux transactions concurrentes (ver- 
rouillage des ressources impliquees) et dont les effets en termes de 
changements d'etat sont durables. Du point de vue d'un systeme d'infor- 
mation, il s'agit d'une unite logique d'execution permettant de passer 
d'un etat coherent a un autre. 


Transaction 


Transaction atomique 


Voir Transaction 


Atomic transaction 


Transaction longue 


Voir Activite 


Long transaction 


Verification 
(de signature) 


Procedure inverse de la signature qui sert a verifier I'identite du signataire 
du document. Si la signature est obtenue par I'application d'un algorithme 
de chiffrement avec une cle privee au condense d'un document, la verifi- 
cation consiste a appliquer I'algorithme de dechiffrement avec la cle publi- 
que et comparer le resultat avec un condense nouvellement calcule. 


Verification 
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ACL (Agent Communication 

Language) 41 
acte de communication 37 

conditions de satisfaction 40 

conditions de succes 39 

pragmatique 39 

semantique 39 

syntaxe abstraite 38 
Actional, SOAPswitch 528 
activation (protocole d') 

Voir protocole 
Active Server Pages 

Voir ASP 

Voir ASP.NET 
activite 766, 767, 795 

metier 810, 980-982 
Acumen Advanced Technologies 

446 



AUDDI-Standard Edition 1.2 
446 
Address Resolution Protocol 

Voir ARP 154 
ADO.NET 552 
AES (Advanced Encryption 

Standard) 148 
agent rationnel 34 
agregation de services 68, 76, 96, 

761,807,831,979 
Alcatel 455 
Allaire 299 

Alliance E-Marketplace 345 
AltoWeb 520, 525 

Application Platform 525 
American Express 345 
analyseur syntaxique 

Crimson 499 

Electric XML 520 

Project X 499 

Xalan 457, 459, 500, 524 

Xerces 457, 459, 500, 524, 526 

XML 191, 456, 854 

XML4J 500 

XSL 456, 854 
Andersen Consulting 345 
annuaire 

LDAP 446 

UDDI 1 16, 346, 348, 395, 397, 
425,439,446,447,500,513, 
633, 826, 865, 867, 898, 925, 
955, 957, 973 

acces programmatique 350 

de production 350, 351, 354, 
397 

de reference 349 

de services 111, 344 

detest 350, 351 

integrite referentielle 425 



prive 395, 459, 485, 509, 514, 
521,936 

public 336, 344, 345, 352, 395, 
459,514,810,865,936 

replication 348 

suppression 416 
annulation (d'une transaction) 764 
AOL 519 
AOS (architecture orientee 

services) 19, 37, 53, 808, 862, 

898 
Apache 336, 340, 457, 459, 498, 

499,500,501,504,524,526, 

527, 730, 998 
API 

DOM 502 

JavaBeans Activation 
Framework 903 

JavaMail 902 

JAXB 508 

JAXM508, 516 

JAXP 503, 508 

JAXR447, 508, 516 

JAX-RPC 1.0 508 

JNDI 520 

SAAJ1.1508 

SAX 502 

SOAP with Attachments 516 

UDDI 

Voir UDDI (API) 

WSDL4J912 
API SOAP de Mozilla 606 

declaration d'un service Web 
606 

declaration d'une methode de 
service Web 607 

invocation asynchrone 609 

invocation synchrone 608 
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appel de procedure distante 

Voir RPC 
application orientee service 23 
arbre de decomposition 

(d'une activite) 766, 796 
architecture 453 

asynchrone 841, 898 

choix 457 

client/serveur 23, 808 

COM/DCOM 457, 496 

connecteur JCA 526 

CORBA 457, 496, 515 

dynamique 841, 842, 898, 997 

EJB 496 

e-Speak 344, 498, 512, 827 

faiblement couplee 102 

fortement couplee 103 

grid computing 521, 526 

J2EE 457 

Jini 343, 344 

maitre/esclave 23 

orientee services 
Voir AOS 

peer-to-peer 526 

statique 841, 842, 898, 975, 978 

Sun ONE 507 

synchrone841,898 

systeme d'information 526 
Ariba 299, 345,441,444 
Arjuna 770 
ARP (Address Resolution 

Protocol) 154 
ASP (Active Server Pages) 464, 

465, 467, 469 
ASP.NET 550, 877, 957, 964 

architecture 552 

authentification 557, 578 

autorisation 559 

configuration 552 

controles de validation 567 

controles serveur 564 

diagnostic 560 

endossement de personnalite 559 

fonctionnement 550 

gestion d'etats 554, 578 

Mobile Web Forms 569 

performances 552 

prise en charge 
multinavigateurs 563 

securite 557 

service Web 569 

Web Forms 560 



ATG 506 

atome BTP 769 

atomicite (d'une transaction) 763 

authentification 56, 693, 697, 701, 

720, 721 

par certificat 724 

par nom d'utilisateur/mot de 
passe 722 
autonomic computing 125 
autorisation 57, 697, 701 
autorite de certification 58, 147 

B 

B2B (Business to Business) 345, 

808 
base de donnees 

Cloudscape 523 

DB2 445, 523, 525 

Hypersonic SQL 445 

Oracle 446, 523, 525 

PostgreSQL 523 

SQL Server 523, 525 

Sybase 523, 525 
Base64 132 
BEA 299, 336, 505-507, 520, 525, 

632, 635, 707, 768, 770, 809- 

813, 822, 825, 853 

WebLogic Collaborate 516 
behavior Internet Explorer 600 
binding 

Voir liaison 
BizTalk.org 809 
Bluestone 516 
BOM (Byte Order Mark) 

Voir Unicode marque de 
polarite 
Borland 506, 525 
Bowstreet 299, 345, 447, 519, 524 

Business Web Factory 524 

Portlet Factory for IBM 
WebSphere 524 
boxcarrying 

Voir envoi groupe 
BPEL (Business Process 

Execution Language for Web 

Services) 43, 77, 768, 770, 801 
BPEL4WS (Business Process 

Execution Language for Web 

Services) 

Voir BPEL 
BPM (Business Process 

Management) 810, 811 



BPMI (Business Process 

Management Initiative) 809, 

811 
BPML (Business Process 

Modeling Language) 43, 809, 

811 
BPMN (Business Process 

Modeling Notation) 824 
BPMS (Business Process 

Management System) 813 
BPQL (Business Process Query 

Language) 809 
BPSS (Business Process Modeling 

Specification Schema) 43, 809 
BPWS4J (Business Process 

Execution Language for Web 

Services Java Run Time) 811, 

821 
BTP (Business Transaction 

Protocol) 77, 768 
business process 

Voir processus metier 
Business to Business 

Voir B2B 
Byte Order Mark 

Voir BOM 



C# 548, 549, 731, 735, 739-740 
CA (Certification Authority) 

Voir autorite de certification 
Callscan 455 
Canonical XML 711 
Cape Clear 446, 457, 470, 471, 

501,515,519,521 

Cape Clear 4 446-447, 521 

CapeConnect 457, 470, 521 

CapeScience 522 

CapeStudio 463, 470-471, 522 

UDDIDirect 447 
Capstone 149 
Cargill 345 
carnet d'adresses 111 
Casewise 824 
CDL (Conversation Definition 

Language) 827 
Certification Authority 

Voir autorite de certification 
CertiNomis 720, 743 
chaine d'acheminement 50, 57, 

205, 694 
chaine de responsabilite 696 
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chiffrement 147, 712, 718-719, 

728 

a cle asymetrique 728 

a cle symetrique 729 

des pieces jointes 718 
Chili !Soft 507 
choregraphie 807-808, 812, 814- 

816, 883 
Choreology 770, 812-813, 823 

Cohesions 1.0 812,823 
chunked transfer encoding 

Voir transfert par tranches 
cipher 

Voir chiffrement 
Cisco 506, 813 
Clarus 345 
cles 147 

privees 147 

publiques 147 

symetriques 147 
CLI (Common Language 

Infrastructure) 455 
CLR (Common Language 

Runtime) 536, 538-539, 541- 

542, 550 
CLS (Common Language 

Specification) 537 
coherence (d'une transaction) 763 
cohesion BTP 769 
Cohesions 770 
Collaxa 519, 524, 770, 822, 975, 

1005 

BPEL Orchestration Server 
822, 882, 897, 975, 984, 1005 

for BEA WebLogic 524, 976 

for IBM WebSphere 524, 976 

for Oracle9i 524 

for Sun ONE 524, 976 

Web Service Orchestration 
Server 524 
COM (Component Object Model) 

334,458,461-462,464,470 

COM/DCOM 458 

serveur 334 
Commerce One 299, 345 
CommerceQuest 345 
Commission Europeenne 371 
communication (protocole de) 

Voir protocole 
Compaq 299, 345, 455 
compensation 766, 804, 980, 982, 

992 



composant 

COM 

Voir COM 

CORBA461,462, 470 

decouplage 459 

EJB 461, 462, 471,486 

Java 470 

logiciel 457 

production de 457-458 

modele 496 
Computer Associates 632, 813 
Computer Sciences Corporation 

824 

e3 824 
condense 700, 710-711, 723, 756 
confidentialite 57, 693, 697, 701, 

720 
confirmation (d'une transaction) 

763 
confirmation en deux etapes 

(protocole bilateral de) 

Voir protocole 
confirmation en une etape 

(protocole bilateral de) 

Voir protocole 
connexion HTTP 134 

persistante 134, 141 

volatile 134 
connexion permanente 657 
ContentGuard 708 
contexte de coordination 777 
contrat 

de securite 700, 702 

de service 25, 26, 29, 53 

executable 106 

ferme 106 

negociable 106 

signe 107 

type 107 
conversation 65, 807, 814, 827-828 

identifiant de 980981, 985 

protocole 
Voir protocole 

cookies 135, 266 
cooperation 

Voir protocole 
coordinateur 782 

d'une transaction 764-765 

interpose 766, 797 
coordination 

application participante 810 



protocole de 
Voir protocole 

CORBA (Common Object Re- 
quest Broker Architecture) 19, 
84, 197, 283, 319, 446, 458, 516 

Corel 455 

couches reseau 
OSI 151 
TCP/IP 153 

courtier 119 

CPA (Collaboration Protocol 
Agreement) 53, 62 

CPP (Collaborative Protocol 
Profile) 53, 62 

CrossWorlds Software 345 

CTS (Common Type System) 537 



DARPA Agent Markup Language 

(DAML) 36, 41 
DataChannel 299 
datagramme 154 
DCE (Distributed Computing 

Environment) 19, 283 
DCOM (Distributed Component 

Object Model) 19, 84 
dechiffrement 147, 713, 719 
Decryption Transformation for 

XML Signature 717 
degre de couplage (des 

applications) 104 
Dell 345, 520 
Departement americain de 

l'energie 527 
DES (Data Encryption Standard) 

148, 699, 730 
Descartes 345 

detail d'erreur SOAP 224, 688 
Developmentor 506, 635 
developpement 

demarche 463, 853, 873, 882, 

898 
environnement 459 
methode 461-462 

approche bottom-up 461, 

525, 831 
approche meet-in-the-mid- 

dle461 
approche top-down 461, 525, 
831 
phase 463 
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digest 

Voir condense 
DIME (Direct Internet Message 

Encapsulation) 594, 632, 811 
dimensionnement 55 
Disco.exe (framework .NET) 591 
disponibilite 56, 63 
dissemination de services 98 
DLL (Dynamic Link Library) 464 
DNS (Domain Name Server) 332, 

449 

lookup 144 
document XML 159, 160, 167, 

337, 341, 344, 459, 815 

bien forme 159 

chiffrement 637 

element fils 161 

element frere 161 

element pere 161 

element racine 161 

extensible 161 

valide 160 
DOM (Document Object Model) 

181 

interfaces 183 
Domain Name Server 

Voir DNS 
DOS (Denial of Service) 56 
DotGNU 456 
doublon 653 

suppression 653, 671, 684, 688 
droit d'acces 57 
DSA (Digital Signature 

Algorithm) 699 
DSTCPty813 
DTD (Document Type Definition) 

160, 206 

des schemas 172 
Dun&Bradstreet371 

D-U-N-S Number 371 
durabilite (d'une transaction) 763 



EAI (Enterprise Application 

Integration) 84, 454, 808, 832 
ebXML (electronic business 

XML) 30, 50, 53, 59, 62, 88, 

809 
Eclipse 459, 498, 500, 821 
ECMA (European Computer 

Manufacturers Association) 454 
ECMA-334 454 



ECMA-335 455 

EDI (Electronic Document 

Interchange) 84, 454, 808 
EDS 506,813 
EJB (Enterprise JavaBeans) 456 

specification 470 
Electron Economy 519 
encoded 

Voir style de codage 
encoding style 

Voir style de codage 
Enigmatec 813 
Enterprise JavaBeans 

Voir EJB 
en-tete SOAP 209 
enveloppe SOAP 207 
environnement de developpement 

453, 456 

Forte for Java 522 

JBuilder 525 

Oracle9i JDeveloper 519 

Sun ONE Studio 522, 525, 853 

Visual Studio .NET 332, 339, 
811,877,957 

VisualAge for Java 503 

WebSphere 

Studio Application 

Developer 332, 447, 503, 
504,821,853 
Studio Site Developer 447, 

504 
Studio Technology Preview 

for Web services 503 
Studio Workbench 503, 504 

Workshop 822, 853 
envoi groupe (des messages) 657, 

692 
Epicentric 299 

Foundation Builder 528 

Foundation Server 528 
Ericsson 810 
erreur SOAP 218, 222 
espace de noms XML 206, 303, 

307-308,311-312,320,327, 

463 

declaration 162, 467 

par defaut 469 

prefixe 162, 469 

version 465 

xmlns 162 
espace de nom, .NET 543 



e-Speak 

Voir Hewlett Packard 
etape zero (protocole bilateral d') 

Voir protocole 
ETSI (European 

Telecommunications Standards 

Institute) 156 
Evans Data Corporation 454 
exactitude 55 
eXcelon 526 
Exclusive XML Canonicalization 

711,717 
Expertlog 770 
extensible Markup Language 

Voir XML 
Extricity Software 345 



fail over 65 

FCL (Framework Class Library) 

Voir .NET 
federation de services 23 
fiabilite 60 

des echanges 60, 72, 647 

des serveurs 63 

fonctionnelle 62 
FIPA (Foundation for Intelligent 

Physical Agents) 41 
fonction de hachage 147 
format 

de message 300 

HTML 461 

MIME 300, 303, 330 

URI 449 

UUID 449 

WSDL 300, 346 

XML 300, 346, 446 
Forte 507 
Foundation for Intelligent 

Physical Agents 

Voir FIPA 
framework 

J2EE 460, 496 

WSIF 340 
framework .NET 336, 447, 455, 

460, 496, 534, 535 

assemblage 538, 578 

attribut 540 

code behind 561, 570, 578 

deploiement 539 

environnement d' execution 
527, 536 

langage 537, 548 

librairie objet 542 
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metadonnees 539, 541 

securite 539 

service Web 569 
FTP (File Transfer Protocol) 324 
Fujitsu 299, 345, 455, 526, 635, 

681,813 

Interstage i-Flow 528 



garantie de livraison d'un message 

653, 670, 688 
generation 

assistant 463 

client de test 490 

code 462 

directives 463 

document WSDL 307, 470, 
498, 520 

formulaire de test 333 

proxy-objet 463 

proxy-service 308, 336-337, 
462-463, 467 
Gibraltar 822 
Global Grid Forum 527 
Globally Unique Identifier 

Voir GUID 
Globus 527 

Globus Tutorial 527 

groupe de travail OGSI-WG 
527 

OGSI Technology Preview 
release 527 

projet OGSA 527 

Toolkit 527 
Glue 457, 463 
Google 303, 311, 314-315, 318, 

320, 323-324, 327, 330 

service Web 599 
GotDotNet 336, 493, 495 
Great Plains 345 
grid computing 

Voir grille d'ordinateur 
grille d'ordinateurs 125 
GUID (Globally Unique 

Identifier) 349, 486 

H 

Hailstorm 534, 597 
handshake protocol 

Voir protocole de negotiation 



Hewlett-Packard 299, 341, 343- 

344, 352, 353, 441, 443-444, 

454-455, 457, 498-499, 506, 

512,516,635,768,770,809, 

813,814,827 

division HP Middleware 344, 
443 

e-Speak 512 

HP Labs 344 

HPNetaction512 

HP Open View 437 

HP Process Manager 512 

HP Registry Composer 445, 
500 

HPTotal-e-Mobile512 

HP Total-e-Syndication 512 

HP Total-e-Transactions 512 

HP Web Services Platform 344, 
512 

HP Web Services Registry 2.0 
445 
Hitachi 526, 681,813 
HTML (HyperText Markup 

Language) 84 
HTTP (HyperText Transfer 

Protocol) 49, 84, 85, 133, 193, 

266, 324, 656, 690 

code de retour 139 

description d'un message 135 

en-tete de type 
entite 139 
reponse 138 
requete 137 
general 137 

GET 136, 141 

POST 136 
HTTPR (Reliable HTTP) 62, 648, 

656 

canal 660 

emetteur 667 

entite 661 

EXCHANGE 666 

GET-RESPONDER-INFO 663 

PULL 665 

PUSH 665 

recepteur 669 

REPORT 666 

session 663 

transaction 660 

I 

i2 345 

IAB (Internet Architecture Board) 
156 



IAI (Internet Application 
Integration) 454, 808 
IANA (Internet Assigned 

Numbers Authority) 156 
IBM 299, 300, 332, 336, 340, 345, 
349-350, 352-354, 360, 395, 
397, 441, 443-447, 455-457, 
460, 484, 497-502, 504, 506, 
516,524,527,627,632,634- 
635, 637, 657, 706-707, 730, 
770,809-812,821,831,853, 
902-903,912,972 
DB2 442 
DB2/XML Extender for DB2 

7.2 503 
Domino Application Server 

503 
Domino Workflow 503 
Knowledge Discovery System 

503 
LearningSpace 503 
messagerie WebSphere MQ 

525 
MQSeries503, 516, 647, 816 
programme PartnerWorld for 

Developers 503 
programme Passport 

Advantage 504 
Sametime 503 
site PartnerWorld for 

Developers 504 
Tivoli 503 
WebSphere 442, 503 

Voir aussi serveur 

d'applications J2EE 
WebSphere Business Integrator 

503,516 
WebSphere Studio Application 

Developer (WSAD) 498 
WebSphere Studio Site 

Developer (WSSD) 498 
WebSphere UDDI Registry 

445 
IBM alphaWorks 354, 447, 498, 
501-502,811 
Business Process Execution 

Language for Web Services 

Java Run Time - BPWS4J 505 
Lotus Web Services 

Enablement Kit 502 
SOAP for Java 502 
UDDI Registry 502 
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IBM alphaWorks (suite) 

Web Services ToolKit 498, 
502, 504, 909 

WebSphere SDK for Web 
Services 502, 504 

WSDL Toolkit 498 

XML and Web Services 
Development Environment 
498, 502 
IBM developerWorks 354, 447 

Open Source Projects 903 
ICANN (Internet Corporation for 

Assigned Names and 

Numbers) 156 
ICMP (Internet Control Message 

Protocol) 154 
IDEA (International Data 

Encryption Algorithm) 148 
idempotence 60 
identite 693 
IDL470 
Idoox445, 519, 522 

IdooXoap 522 

WASP 1.0 522 
IESG (Internet Engineering 

Steering Group) 156 
IETF (Internet Engineering Task 

Force) 156, 349, 446, 635 
HOP (Internet Inter-ORB 

Protocol) 195, 197,283,319 
IMAP (Internet Mail Access 

Protocol) 144 
Infosys Technologies 824 

Choreo 824 
infrastructure commune de 

langages 

Voir CLI (Common Language 
Infrastructure) 
Infravio, Web Services 

Management System 528 
Inspire It 447 

UDDI Client 1.0 447 
Instantis, SiteWand 528 
instrumentation (d'un contrat de 

service) 110 
Intalio 809, 813, 825 

n3 824 
integrite 58, 693, 697, 701, 720 
Intel 299, 454, 455, 635, 810 



IntelliSense 583 
interface 37 

abstraite 37, 38 

concrete 37, 45 

implementation 37 
interKeel 506 
Internet Capital Group 345 
Internet Control Message Protocol 

Voir ICMP 
Interopathon 626 
interoperabilite 625 

banc d'essai 627 

confrontation 625 

cycle 626 

divergence 626 

laboratoire 626, 633 

resultat 626 

test 626, 629, 815 
Interwoven 506, 523 
IONA Technologies 299, 332, 

336, 446, 470, 500, 506, 515, 

519,521,631,634,813 

Orbix E2A Application Server 
Platform 515 

Orbix E2A Web Services 
Integration Platform 515 
Collaborate Enterprise 

Integrator Edition 516 
XMLBus Edition 332, 516 

Web Services Interoperability 
Forum 516 
IOR (Internet Object Reference) 

197 
IP (Internet Protocol) 332 
iPlanet 507 
IronFlare 518 
IRTF (Internet Research Task 

Force) 157 
IS API (Internet Server API) 464 

filtre 465 
ISE 455 
ISO (International Organization 

for Standardization) 349, 371 

comite ISO/IEC JTC 1 455 

comite JTC 1/SC 22 455 

normes 455 

projet ISO/IEC DIS 23270 455 

projet ISO/IEC DIS 23271 455 

standard ISO/IEC 11578 
1996 349 



ISO/IEC (International 

Organization for 

Standardization/International 

Electrotechnical Commission) 

708 
ISOC (Internet Society) 157 
isolation (d'une transaction) 763 



J2EE (Java 2 Enterprise Edition) 

457-458,497,512,516,521, 

635, 730 
J2SE (Java 2, Standard Edition) 

499, 730, 743 
Jacada, Integrator 528 
Jamcracker 299 
Java 454, 497, 499, 501-502, 521, 

629 

APIs WSDL (JWSDL) 506 

APIs XML 

XML Binding (JAXB) 506 
XML Messaging (JAXM) 506 
XML Parsing (JAXP) 499 
XML Processing (JAXP) 

506 
XML Registries (JAXR) 506 
XML RPC Calls (JAX/RPC) 
506 

environnement 461 

Java/COM 458 

Javadoc 460 
JAX Pack 447, 508 
JAX/RPC (Java API for XML 

Remote Procedure Calls) 506 
JAXB (Java API for XML 

Binding) 456, 506 
JAXM (Java API for XML 

Messaging) 506 
JAXP (Java API for XML Parsing) 

499 
JAXP (Java API for XML 

Processing) 456, 506 
JAXR (Java API for XML 

Registries) 447, 506 
JAX-RPC (Java API for XML 

Remote Procedure Calls) 456 
JCA (Java Connector 

Architecture) 526, 832 
JCP (Java Community Process) 

454, 456, 498, 499-500, 503 



Index 



1047 



jeton de securite 700, 702, 715, 

721,756 

binaire 715, 721 
Jini 19, 521 
JMS (Java Message Service) 62, 

502,516,648,816 

file d'attente 319 
JNDI (Java Naming and Directory 

Interface) 520 
JSP (JavaServer Pages) 

librairie de balises 509, 517 

page 517 
JSR (Java Specification Request) 

499, 500, 506 

JSR03 1506-507 

JSR063 506-507 

JSR067 506-507 

JSR093 506-507 

JSR101 506-507 

JSR 109 506 

JSR110 506,903 

JSR175 990 
Jupiter 821 

JVM (Java Virtual Machine) 520 
JWSDL (Java APIs for WSDL) 

506 
JWSDP (Java Web Services 

Developer Pack) 447 

K 

KEA (Key Exchange Algorithm) 

149 
keep-alive 

Voir connexion permanente 
Kerberos 699, 701, 708 
Killdara, Vitiris 528 
KQML (Knowledge Query 

Manipulation Language) 41 



Laboratoire National Argonne 527 
langage 

a balises (markup language) 
159 

a machine virtuelle 628 

C527 

C# 336, 337, 454-455, 463, 
493, 842, 877, 956, 972 

C++ 466, 628 

CDL 344 

compile 628 



de description de service 300 

de programmation 496 

de scripting 628 

Erlang 810 

interoperabilite 458 

Java 343, 354, 463, 499, 527, 
628, 842, 972 
normalisation 505 

JavaScript 842, 845 

Perl 628 

PHP 628 

PL/SQL 519 

Python 628 

Ruby 628 

Smalltalk 628 

Tel 628 

VBScript 493 

Visual Basic 469, 628 

WSDL 302, 344 

XML 345, 456, 496, 808-809 

XSL 628 
LDAP (Lightweight Directory 

Access Protocol) 446, 507 
Lectrosonics 632 
legacy systems 453, 458, 832 
liaison 48, 201,265 

SOAP/HTTP 266 
Liberty Alliance 529, 707 
Linux, portage de .NET 455 
liste de controle d'acces 57 
literal 

Voir style de codage 
livraison d'un message 

au moins une fois 653, 671, 681 

au plus une fois 653, 671, 688 

en sequence 652, 672, 684, 681 

exactement une fois 652, 671, 
688 

par priorite 653, 672, 688 
LLC (Logical Link Control) 151 
Loudcloud 345 

M 

MAC (Medium Access Control) 

151 
machine. config 553 
Macromedia 344, 506, 632, 633 

Flash 619, 620 
Mail eXchanger 

Voir MX 
managed code 537 
manifest 538, 539 



markup language 

Voir langage a balises (markup 
language) 
match21 345 

MD5 (Message Digest) 148 
mean time 
to failure 

Voir MTTF 
to repair 
Voir MTTR 
Mercator 523 
Merrill Lynch & Co 345 
message 152, 154 

a sens unique 265, 268 
correlation de 980 
d'erreur 222 

SOAP 218-219, 269 
definition 45 
format 46 
styles d'echange 45 
one-way 
Voir message a sens unique 
META Group 454 
Microsoft 299-300, 332, 336, 345, 
349-350, 352-353, 354, 360, 
395, 397, 441, 444, 446, 454- 
455,463,470,505,627,631- 
632, 633, 634, 635, 637, 639, 
706-707,730,770,809-812, 
821,831,853,857,877,955 
.Net Server Family 445 
BizTalk Server 345, 809, 821, 

831 
Commerce Server 821 
Content Management Server 

821 
Enterprise UDDI Services 445 
Internet Explorer 842, 845, 

854, 865, 903 
Internet Information Server 5.0 

955 
messagerie MQ 525 
MSDN 903, 956 
Office 822 
Office XP Web Services 

Toolkit 2.0 447 
SDK UDDI .NET 447, 955- 

956, 973 
SDK UDDI vl.5 for Visual 

Studio 6 447 
shared source license 455 
SOAP Toolkit 332, 463 
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Microsoft (suite) 

Visual Studio 447 

Visual Studio .NET 447, 535, 
561,564,822,955-956 

WebService Behavior 600, 
845, 854, 865, 903, 908, 976 
MIME (Multipurpose Internet 

Mail Extensions) 132-133, 

135, 144, 254, 300 
Mindreef 632 
modele 

d' implementation 32, 53, 82 

fonctionnel 34, 82 
MOM (Message Oriented 

Middleware) 648 
Momentum Software 823 

ChoreoServer for .NET 823 
Monash University 455 
Mono 456 

monoreferencee (donnee) 243 
moteur d'execution 454, 456, 470 

Apache Axis 354, 398, 459, 
500, 502, 504, 526, 527, 746, 
749, 882, 902-903, 999 

Apache SOAP 336, 354, 440, 
502, 524, 526, 865, 882, 902 

Glue Professional 865 

Hewlett-Packard SOAP 354, 
902 

J2EE 336, 527 

XML 446, 525 
moteur d' orchestration 813, 816 
Motorola 506 
Mozilla 

navigateur 846 

Voir API SOAP de Mozilla 
MSIL (Microsoft Intermediate 

Language) 537-538, 541 
MSMQ (Microsoft Message 

Queuing) 648, 816 
MTA (Mail Transfert Agent) 144 

passerelle 144 

serveur destinataire 144 

serveur relais 144 
MTTF (mean time to failure) 63 
MTTR (mean time to repair) 63 
MUA (Mail User Agent) 144 
MX (Mail exchanger) 144 



N 

NAICS (North American 

Industrial Classification 

System) 366, 438 
namespaces 

Voir espace de noms XML 
Napster 526 
NASA 527 
NASSL (Network Accessible 

Service Specification 

Language) 300 
National Center for 

Supercomputing Applications 

527 
Nations Unies 371, 809 
NBS (National Bureau of 

Standards) 149 
NEC 526, 681 
negociation 110, 121 
NetBeans 519,522 
Netcraft 495 
NefDynamics 519 
Netscape 455, 519 

navigateur 846 

Voir API SOAP de Mozilla 
NetWare 516 
New Era of Networks (NEON) 

345 
NeXT519 
NIST (National Institute of 

Standards and Technology) 

149, 699, 709 
nceud de communication 300-301, 

315-316,318,331 
non-repudiation 58 
Nortel Networks 345 
North American Industrial 

Classification System 

Voir NAICS 
notification 

d'issue (protocole bilateral de) 
Voir protocole 

des changements UDDI 449 
Novell 446, 516, 518, 813 

eDirectory 446 

exteNd517 

exteNd Composer 517 

jBroker518 

Nsure UDDI Server 446 

Workbench 517 



NSA (National Security Agency) 

149, 699 
NTT Communications 345, 349, 

395,441-444 



O'Reilly Network 455 
OakLeaf Systems 639 
OASIS (Organization for the 

Advancement of Structured 

Information Standards) 30, 54, 

59, 77, 87-88, 448-449, 635, 

706,708,768,811 

comite technique UDDI 
specifications 449 

ebXML 50 

norme 458 

standard 448, 449 
ObjectWeb 770 
objet 

par reference 196 

par valeur 198 
Office XP 

Voir Web Services Toolkit 2.0 

pour Office XP 
OGSA (Open Grid Services 

Architecture) 78, 125, 526, 527 
OGSI (Open Grid Services 

Infrastructure) 527 
OMA (Object Management 

Architecture) 19 
OMG (Object Management 

Group) 19, 283 
OMI (Open Management 

Interface) 78 
Open Grid Services 

Voir OGSA 
Open Group 19 
Open Source 354, 447, 455, 457, 

459, 498, 500, 504 
OpenLink 632 
OpenWave 455 
Oracle 299, 446, 506, 518, 526, 

632, 635, 681, 768, 812-813 

Dynamic Services Framework 
518 

Oracle Technology Network 
518 

Oracle9iAS Containers for 
J2EE 446 

Oracle9iAS 446 

Oracle9iAS UDDI Registry 446 
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ORB (Object Request Broker) 283 

Orbix 2000 470 

OrbixWeb 470 

VisiBroke 470 
orchestration 807, 812, 814, 815 

balise (d') 990, 991 

invocation asynchrone 816 

invocation synchrone 816 

regies (d') 816 

serveur (d') 991 
organisation 

professionnelle 344 

UDDI514 

WS-I 504 
organisme de normalisation 344, 

448 
OSF (Open Software Foundation) 

283 
OSI (Open System 

Interconnection - ISO/IEC 

7498) 150 



paquet 152 
paquetage 

Java Web Services 
Development Pack (JWSDP) 
456 

JAX Pack 456 

jUDDI 447 

SOAP4J 498, 500 

UDDI 2.0 504 

UDDI4J 353, 354, 397, 445, 
447, 498, 500, 504 

WSDL4J 498, 500, 524, 903, 
951,972 

WSIL4J 340 

XML4J 499 
pare-feu 832 
parseur 

Voir analyseur syntaxique 
Partner Interface Process 

Voir PIP 
passerelle 134 
Passport 557 
patrimoine applicatif 453 

Voir aussi legacy systems 

recuperation 
peer-to-peer 23 
PeopleSoft516 
performance 55 
pi-calcul 810 



piece jointe 202, 253, 692 
PIP (Partner Interface Process) 

345, 810 
pipe-line 657 
pipelining 

Voir Transfert en pipe-line 
place d'echange 123 
place de marche 123, 345 
plate-forme 

.NET 454, 459, 463, 533, 898, 
955, 957 
Voir aussi framework .NET 

autonome 457 

choix 457 

e-Speak 344 

grille informatique orientee 
services 526 

IBM WSDK 504 

IBM WSTK 463, 504 

interoperabilite 453 

J2EE 454, 456, 497, 499 

J2SE 456 

Java 460, 499, 855, 898,957 

logicielle 496 

materielle 496 

part de marche 454 
plate-forme d'execution 459, 464, 

470 

equilibrage de charge 527 

gestion de grappe de machines 
527 

Glue Professional 926 

JRE 505 

Oracle9iAS Containers for 
J2EE519 

reprise sur incident 527 
plate-forme de deploiement 453 

de services Web 525, 526 

Glue Professional 926 

Oracle9iAS Containers for 
J2EE519 
plate-forme de developpement 

Borland JBuilder 523 

de services Web 525 

Eclipse 523 

Glue Professional 926 

IBM WSAD 523 

JDK 505 

Sun ONE Studio 523 
plate-forme de gestion 

collaborative 516 
Platform 527 



Plum Hall 455 

plurireferencee (donnee) 243 
PocketSOAP 629 
point d'acces 626, 627 
PolarLake 519, 524 

Database Integrator 525 
Messaging Integrator 525 
plate-forme de deploiement 

524 
Web Services Express 524 
POP (Post Office Protocol) 144 
Popkin Software 824 
port 49 

TCP 155 
PRISM (Publishing Requirements 
for Industry Standard 
Metadata) 36 
processus 299 

processus metier 42, 761, 807, 
810,813,841,881,898,975 
abstrait 818 

comportement dynamique 813 
executable 818 
gestion 458, 524 
implementation privee 818 
integration 345, 458 
interentreprises 832 
interface publique 814, 818, 

823 
interface statique 813 
modelisation 809, 813 
participant 813 
PIP 345 

processus abstrait 43 
processus executable 43 
profil de base WS-I 200 
Progress Software 520, 526, 813 
protocole 
bilateral 

d' accord 798 

avec terminaison 801 
d'etape zero 791, 794 
de confirmation en deux eta- 

pes 787, 794 
de confirmation en une etape 

790 
de notification d' issue 792 
de terminaison 786, 794 
avec acquittement 787 
d' activation 774 
de communication 761 
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protocole (suite) 

de confirmation en deux etapes 

764, 794 
de conversation 42, 762, 829 
de cooperation 76 1 
de coordination 761, 772, 783, 

810 

des activites 795 

des transactions 783 
de negociation 148-149 
d'enregistrement 148 
de registration 779 
de reseau 300 
de transport 300, 626 

abstraction 340 

FTP 525 

HTTP 525 

JMS 340, 521 

SMTP 525 

SOAP 299, 320, 323, 340, 
468 
HTTP GET/POST 300, 303, 

319,330 
HTTPR 656 

HTTPS 348, 350-351, 398-399 
HOP 319 
Java/RMI319 
RMI 343 
SOAP 319, 346, 399, 440, 845, 

865, 898, 978 

listener 465 
SOAP 1.1 300,324 
SSL 3.0 397 
proxy 134, 580, 615, 617, 621-622 
proxy-objet Java 343 
proxy-service Java 343 

Q 

QP (Quoted-Printable) 132 
qualite de service 5 1 



RARP (Reverse Address 
Resolution Protocol) 154 

Rational Software 345, 506 

rationalite (principe de) 34 

RC2 et RC4 148 

RDF (Resource Description 
Framework) 36 

RealNames 345 



record protocol 

Voir protocole 

d'enregistrement 
Red Hat, portage de .NET 455 
referentiel des contrats 111 
registration (protocole de) 

Voir protocole 
repertoire des fournisseurs 111 
respect de la sequence des 

messages 653, 671, 688 
revendication 702 
Reverse Address Resolution 

Protocol 

Voir RARP 
RFC (Request For Comments) 156 

RFC1738 131 

RFC2045 132 

RFC2046 132 

RFC2047 132 

RFC2048 132 

RFC2049 132 

RFC2141 132 

RFC2368 131 

RFC2396 130 

RFC2616 131, 133 

RFC2717 131 

RFC2774 136 

RFC2821 143 

RFC2822 144 

RFC2965 134 

RFC792 154 

RFC826 154 

RFC903 154 

RFC-editor 157 
RMI (Remote Method Invocation) 

195,283,319 
robustesse 59 
Rogue Wave 299 
RosettaNet 345, 810 
Rotor 455 
routage 152 
routeur 

Voir aussi chaine 

d'acheminement 
RPC (Remote Procedure Call) 23, 

46-48, 193,202,265,283,316 

appel 630 
RSA 148, 698-699, 756 

RSA Key Exchange 149 
RSA Security 707 



Sabre Holdings 345 
SalCentral 460 
salon 

JavaOne 456, 507 

NetWorld+Interop 516 
SAML (Security Assertion 

Markup Language) 59, 708 
SAP 299, 345, 349, 353, 395, 441- 

444,449,506,516-517,635, 

707,809,813,825 
SAX (Simple API for XML) 191 
scenario 

BPEL 815, 821, 882, 885, 895, 
976,978,991 

JBPEL 978 
SCL (SOAP Contract Language) 

300 
SDK (Software Developement 

Kit) 499 

J2SE 499, 902, 976 
SDL (Services Description 

Language) 300 
Secure Hash Algorithm 

Voir SHA-l 
Secure Socket Layer 

Voir SSL 
securite 56, 146 

de bout en bout 695 

point a point 695 
SeeBeyond Technology 813 
serveur d'applications IIS 5.0 

334, 336, 495, 877, 957 
serveur d'applications J2EE 336, 

457, 862 

Apache Tomcat 336, 501, 525, 
845,865,877,882,901,902, 
960, 976 

Bluestone 499 

Blue stone Sapphire /Web 512 

Bluestone Total-e-Server 512 

HP Application Server 512 

iPlanet 470, 486 

JBoss 976 

Jetty 976 

JRun 4.0 344 

Oracle9i518 

Orbix E2A 336 

Orion 518 

part de marche 516 

Tomcat/JBoss 525 
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WebLogic 336, 457, 470, 516, 
524, 525, 822, 901 

WebSphere 336, 445, 457, 470, 
500,502,503,516,525 

WebSphere Technology 
Preview 502, 503 
serveur SMTP 

Voir MTA (Mail Transfert 

Agent) 
service 457, 458 

client 459, 461 

concepteur 459, 463 

consommateur 462 

contrat 457 

demandeur 459 

fournisseur 459, 461 

implementation 463 

interface existante 461 

methode 464 

nouvelle interface 461 

specification 459 

stateful 65 

stateless 65 
service Web 84, 300 

de deuxieme generation 461 

de premiere generation 461 

invocation asynchrone 526, 
1004 

invocation synchrone 1004 

liaison dynamique a 
1' execution 462 

liaison dynamique a la 
construction 462 

liaison statique 462 

WebService Browser 493 

WsdlVerify 493 
SHA (Secure Hash Algorithm) 

698, 699, 722, 725, 756 
SHA-1 148 
Shinka Technologies 501, 515, 

519 
Siebel516 
signature 58, 147, 710, 717, 726, 

730 

a cle asymetrique 726 

par secret partage 726 
SilverStream 506, 516, 518 

Application Server 517 

Composer 517 

Director 517 

eXtend 516 

jBroker 517 



Workbench 517 
skeleton 285 
SKIPJACK 148 
SLA (Service Level Agreement) 

51 
SMTP (Simple Mail Transfer 

Protocol) 143, 324 

commandes 145 

description d'un message 144 

transmission d'un message 144 
sniffer 141 
SOA (Service Oriented 

Architecture) 

Voir AOS 
SOAP (Simple Object Access 

Protocol) 47, 48, 49, 54, 62, 85, 

195, 299, 454, 459, 703 

attribut actor 630 

attribut d'encodage array Type 
311 

attribut mustUnderstand 630 

code d'erreur 222 

communaute 516 

corps 207, 218, 324 

decodage 628 

destinataire 204 

detail d'erreur 222 

document/literal 629 

emetteur 205 

encapsulation 50 

encodage 628, 629 

en-tete 207, 320, 324, 629-630 

enveloppe 208, 324, 628 

erreur 222 

expediteur 204 

du message d'erreur 222 

gestion des erreurs 218 

libelle d'erreur 222 

messagerie asynchrone 632 

rpc/encoded 629, 639 

schema d'encodage SOAP 1.1 
311 

section 5 629-630, 639 

section 7 629 
SOAP Toolkit 463 
SOAPBuilders.org 626, 627, 629, 

631-633 
SOAPClient (site Web) 629 
SoapContext 592 
soaplite.com 627 
SoapWare.org 454 



socket 155 
Software AG 813 
Sonic Software 506, 520, 526, 
632,681 
Sonic MQ 526 
Sonic XQ 526 
SourceForge 498, 770 
specification (references a la) 
BPEL4WS 505, 524, 812, 818, 

842, 899, 975, 1004 
BPML812, 824, 825 
BPSS812 

BTP524, 811,812, 823 
CSS level 1 855 
cXML345, 515 
Document Object Model Level 

1499 
ebXML515 
EDI 515 
e-Speak 344 

Grid Service Specification 527 
HTTPR 498 
JavaScript 1.3 855 
JavaServer Pages 501 
JCP 499 
JMS 502 
RosettaNet 515 
SAML516 
SAX 499 
Servlets 501 
Servlets 2.3 520 
SFS 344 
SOAP 341, 345, 498, 516, 518, 

524, 525, 526, 527, 635, 808, 

842, 899 
SOAP 1.1 502,636 
SOAP with Attachments 508 
UDDI 309, 341, 347, 498, 516, 

518,525-526,635,808,842, 

899 
UDDI 1.0 352, 441,447, 502 
UDDI 2.0 352, 372, 397, 441, 

445-449, 502, 637 
UDDI 3.0 352, 445, 447-449 
UDDI 4.0 450 
W3C 499 
Wf-XML811 
WSCI812, 824 
WSCL341,812, 814 
WS-Coordination 505, 811, 

820, 842, 899, 975, 1004 
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specification (references a la) 

(suite) 

WSDL300, 303, 341,439, 
498,516,518,524,525-527, 
635,808,818,824-825,831- 
833, 842, 845, 899 

WSDL1.1502, 636, 825 

WSDL1.2 812, 825 

WSFL 498 

WSIL516, 527 

WS-Inspection 527 

WS-Reliability 526 

WS-Security 498 

WS-Transaction 505, 8 1 1 , 820, 
842, 899, 975, 1004 

xCBL515 

XHTML 1.0 855 

XML 1.0 499, 635 

XML Namespaces 1.0 499 

XML Schema 301, 308, 628, 
818,824-825,832 

XML Schema 1.0 312, 637 

XML Schema 2001 501 

XPath818, 824, 825 

XQuery 824 
SpiritSoft, messagerie SpiritWave 

525 
SQL (Structured Query Language) 

449 
SSL (Secure Socket Layer) 146, 

195,694,719 

methodes de chiffrement 148 

presentation generate 147 

protocole de negociation 149 
Sterling Commerce 824-825 

Integrator 824 
STR Dereference Transform 717 
structure SOAP 239, 246 
stub 284 
style d'echange 201, 265 

document 842 

message a sens unique 204, 
265, 268, 677 

requete/reponse 204 
asynchrone 679 
document 198, 204, 265 
RPC 204, 265, 283, 290 
synchrone 672 

RPC 842, 898 
style de codage 49, 201, 232 

code 263, 842 

contenu code 202 



contenu litteral 202 
encoded 233 
litteral 232, 263, 842 
SOAP 1.1 291, 294, 295 

Sun Microsystems 343-345, 398, 
447, 454-456, 470, 498-500, 
505-506, 521-522, 526, 632- 
633,636,681,707,730,809, 
813,825,853,902,976 
Sun ONE WSCI Editor 826 

SwA (SOAP with Attachments) 
632 
Voir aussi piece jointe 

Sybase 506 

systeme d'exploitation (references 
au) 

FreeBSD 455, 456 
Linux 456, 503, 507 
Linux Red Hat 455, 504 
Linux Red Hat 7.1 445 
Linux Red Hat 7.2 470 
Linux SuSE 7. 1445, 504 
Mac OS X 456 
Solaris 507 
Solaris 2.6 470 
Solaris 2.8 470 
systeme de fichiers 926 
Windows 456, 503, 507 
Windows 2000 445, 464, 504, 

842, 877, 902, 956-957 
Windows 2000 Server 957 
Windows 2000 SP1 464, 470 
Windows 2000 SP2 470 
Windows 98 464 
Windows ME 464 
Windows NT 502 
Windows NT 4.0 445 
Windows NT 4.0 SP6 464 
Windows NT 4.0 SP6a 470 
Windows XP 447, 455, 504 

systeme d' information 454, 808, 
813,901 

architecture 453, 457 
connexion 454 
decouplage 459 
extension 453 
integration 461 
interconnexion 832 
refonte globale 458 
reparti 625 
restructuration 461 
urbanisation 454 



Systinet 445-446, 457, 519, 522- 
523, 632-633 
WASP Developer 445 
WASP OEM Edition 523 
WASP Server 445, 522, 909 
WASP UDDI 4.5 445, 448 



tableau 

SOAP 313 

Voir vecteur SOAP 

XML Schema 313 
tache 766, 795 
Talking Blocks, Web Services 

Management System 529 
TCP/IP, couches 153 
TCP/IP (Transmission Control 

Protocol/Internet Protocol) 

154, 332 
temps de latence 60 
Tengah 516 
terminaison (protocole bilateral 

de), avec acquittement 
Voir protocole 
Thawte 720 
The Mind Electric 445, 457, 463, 

519-520,634 

Electric XML 520 

Gaia521,526 

Glue 501, 520, 909 

Glue Professional 445, 865, 
926, 973 

Glue Standard 445 
TIBCO Software 299, 345 

messagerie Rendezvous 525 
tiers de confiance 58, 700 
Tiger 456 
TLP (Transport Layer Protocol) 

146 

methodes de chiffrement 148 

presentation generale 147 

protocole de negociation 149 
TLS (Transport Layer Security) 

694,719 
trame 151, 153 
transaction 66, 152, 759, 767 

atomique 766, 810 

centralisee 69 

compensatoire 74 

contexte de 99 1 

courte 816, 881 

explicite 70 
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imbriquee 72 

implicite 69 

longue766, 816, 881 

participant 992 

repartie 73 
transfert 

de la conservation UDDI 449 

de la propriete UDDI 449 

en pipe-line 267 

par tranches 268, 657 
Triple DES 

Voir DES 
try on failure 64 
tunnel 134 
Two-phase commit 

Voir confirmation en deux 

etapes 
typage des donnees 231, 303 

dynamique 231, 236 

statique 23 1 
type de donnee 

complexe 470 

composite 245 

simple 239 

U 

UBL (Universal Business 

Language) 233 
UBR (UDDI Business Registry) 

345, 440, 443, 448 

operateur441,442 
UDDI (API de publication) 349, 

396-937 
UDDI (API de recherche) 349, 

354,416,436,938 
UDDI (Universal Description, 

Discovery and Integration) 30, 

49, 54, 86, 301, 345, 459, 498, 

507, 816 

acces a l'annuaire 348 

administrateur UDDI 35 1 , 395, 
396-397, 442 

assertion 397, 425-427, 429- 
432, 434, 436 
incomplete 435 
validee 435 

banc d'essai 633 

Builders 633 

canal d' acces 396 
standard 439 

client 633 



communaute 352, 441, 448, 

514 
compte 

administrateur 397 

d' acces 396 
convention d'appel 437 
definition 
d' implementation de service 

439-440 
d' interface de service 439-440 
implementation 625 
jeton d'authentification 396, 

398-401, 403, 405, 409, 412- 
413,417-418,420,422-424, 
426-427, 430, 435 
librairie cliente 633 
modele 

d'information 347 

d'invocation 436 
operateur 395, 514 
page 

blanche 347 

jaune 347 

verte 347 
pile d'interoperabilite 346 
relation entre entites metier 427 
replication 449 
serveur 633 
taxonomie 415, 438 

de categorisation 408 

Dun & Bradstreet 371-372, 
438 

GEO 366, 370-371,404, 
406, 408, 414, 438 

ISO 3166 Geographic Taxo- 
nomy 438 

NAICS 366-367, 369-371, 
404, 406, 408, 414, 438 

ntis-gov:sic: 1987 381 

sec-gov:cik-key 381 

standard 347 

Thomas Register 372, 438 

uddi-org:relationships 374 

uddi-org:types 382, 416 

UNSPSC 366, 368-370, 404, 
406, 408, 414, 438 

ws-i-org:conformsTo 408, 
416 
UDP (User Datagram Protocol) 
154 



UN/CEFACT (United Nations 

Centre for Trade Facilitation 

and Electronic Business) 809 
Unicode 

BOM 310 

marque de polarite 628 
University of Maryland 813 
UNSPSC (Universal Standard 

Products and Services 

Classification) 366, 438 
URI (Uniform Resource 

Identifier) 84, 85, 324, 465 

absolu 256 

base 256 

par defaut 258 

composition 131 

jeu de caracteres 130 

relatif256 

syntaxe 130 
URL (Uniform Resource Locator) 

336 
URN (Uniform Resource Name) 

132 
UUID (Universal Unique 

Identifier) 349, 358, 419, 449 



validation (de signature) 711,718 
vecteur SOAP 239, 249 

a plusieurs dimensions 25 1 

creux 253 

de vecteurs 25 1 

transmis partiellement 252 
Ventre 345 
Vergil Technology 823 

Web Services Orchestration 
Suite 823 
Verio 442 

VeriSign 299, 345, 706-707, 720 
verrouillage (d'une ressource) 765 

en deux phases 769 
Versata 345 
VerticalNet 345 
View State 555 
Vitria 299 
vocabulaire 

metier 344 

XML 

Voir espace de noms XML 
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W.W Grainger 813 
W3C (World Wide Web 

Consortium) 54, 87, 157, 200, 

300, 499, 505, 635, 808-809, 

812, 825, 827, 857 

activite Web Services 300 

atelier Workshop on Web 
services 827 

groupe de travail Web Services 
Architecture 812 
Choreography 812, 825 
Description 300 
XML Protocol 200 
Web semantique 635-636 
Web Service Enhancements 

Voir WSE (Web Service 
Enhancements) 
Web Services Conversation 

Language 

Voir WSCL 
Web Services Description 

Language 

Voir WSDL 
Web Services Interoperability 87 

Organization 
Voir WS-I 
Web Services Invocation 

Framework 

VbiVWSIF 
Web Services Tool Kit 

Voir WSTK 
Web Services Toolkit 2.0 pour 

Office XP 613 
Web.config 553-554, 556, 558, 

560, 579, 591, 593, 595 
WebGain 506 
Web Matrix 561, 541, 575, 579, 

585 
WebMethods 299, 345, 506, 632- 

633,813 

Integration Server 631, 575, 
578, 585 
WfMC (Workflow Management 

Coalition) 809, 811 
Whistler 445 

White Mesa 629, 631-632 
workflow 808-809, 815, 832 

documentaire 808 
WS-Attachments 594, 811 
WS-Authorization 703, 706 



WSCI (Web Services 

Choreography Interface) 43, 
809,811,825 
WSCL (Web Services 

Conversation Language) 43, 
341,809,827 
WS-Coordination 77, 768, 770, 
810-811 
Activation 

Voir activation (protocole de) 
Registration 
Voir registration (protocole de) 
WSDC (Web Services 

Development Concepts) 461 
WSDK (Web Services 

Development Kit) 811 
WSDK (WebSphere SDK for Web 

Services) 504 
WSDL (Web Services Description 
Language) 41, 49, 54, 85, 237 
balise import 307 
definition d' interface de service 

439 
description 461 

de service 463 
document 303, 341, 440, 459, 

460, 463, 469 
encodage UTF-16 466 
encodage UTF-8 466 
espace de noms 303 
exemple 303 
fichier 63 1 
format 463 

generer avec SOAP Toolkit 463 
generer par GotDotNet 493 
implementation 625 
importation de fragment 307 
interaction 

a sens unique 315 

de type demande de reponse 

315 
de type notification 316 
de type requete/reponse 315 
lecture par un navigateur 493 
liaison 301, 317 
GET/POST 319, 330 
MIME 319, 330 
standard 319 
manipulation 500 
message 301, 313 
operation 301 



port 301, 318 
alternatif 319 

processeur 310 

service 301, 318 

specification 299 

style 325 

decodage SOAP 1.1 313 
document 314, 324, 326-327 
rpc314, 317, 324, 326-327 

transformation 460 

type 301, 310 
deport 301, 314 

usage 
code 291 
litteral 29 1 

verification 336 
WSDL.exe (framework .NET) 592 
WSE (Web Services 
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Services Web 

Pour faire interagir de maniere fiable, souple, securisee et transactionnelle, des applications 
heterogenes au sein d'architectures orientees services, il faut integrer les notions de contrat, 
de processus et de conversation metier, mais aussi maitriser les environnements d'execu- 
tion en evitant les derives proprietaires qui reduisent I'interoperabilite. 

Une reference pour les developpeurs accompagnee cl 'etudes de cas 

Cet ouvrage avant tout destine aux developpeurs et aux architectes explique la mise en ceuvre d'architectures repar- 
ties sur des plates-formes heterogenes et mixtes, aussi bien cote serveur (J2EE, .NET) que sur le poste de travail 
(Internet Explorer, Mozilla, Flash, Microsoft Excel XP...1, en mettant I'accent sur la description des processus 
metier avec BPEL. 

Les techniques d'infrastructure ayant trait a la securite, a la fiabilite et aux transactions telles que WS-Security, 
WS-Transaction, WS-Coordination, sont presentees en detail, non sans un rappel approfondi des normes fonda- 
trices [SOAP 1.1 et 1.2, WSDL et UDDI), de leurs dernieres implementations et des recommandations 
d'interoperabilite WS-I. 

Au sommaire 

['ARCHITECTURE ORIENTEE SERVICES • Le contrat de service • Le qualite de service. Fiabilite, disponibilite, 
continuity, performances, securite et gestion transactionnelle • Les architectures dynamiques. Agregation et 
dissemination de services. Niveaux de configuration dynamique. Negociation • TECHNOLOGIES DES SERVICES WEB 
. Protocoles Internet (URI, URN, URL, MIME, HTTP/1.1, SMTP, SSL, TLS). Technologies XML (XML, XML 
Namespaces, XLink, XML Base, XPath, XML Schema, DOM) . Echanger auec un service en SOAP. SOAP 1.1 
et 1.2. Structure du message. Gestion des erreurs. Mecanismes de codage: usage litteral, usage code. Pieces 
jointes. Styles d'echange: unidirectionnel, requete/reponse, RPC, document, synchrone, asynchrone • Decrire un 
service avec WSDL. Liaisons SOAP, HTTP GET/POST, MIME • Decouvrir et publier un service avec ODDI 1.0 et 
2.0. Structure d'un annuaire UDDI. API de decouverte et de publication. Correspondence WSDL/UDDI. 
Implementations : annuaire public replique (UBR1, annuaires prives. UDDI 3.0 . PLATES-FORMES OPERATIONNELLES 
. WSDL comme pivnt. Transformer un composant en service (MS SOAP Toolkit, Cape Clear CapeStudio). Generer 
des proxy-services (MS .NET Framework, IBM Web Services Toolkit], squelettes de service (Cape Clear 
CapeStudio), clients de test (Cape Clear CapeStudio, WebService Browser) • Plates-formes Java. Apache SOAP 
4J, Xerces, Tomcat, Axis (implementation de reference). IBM WebSphere. Sun ONE. BEA WebLogic, mais aussi 
Glue, CapeConnect, Systinet WASP, Collaxa... . Plate-forme .NET. WSE. Framework .NET. ASP .NET. Web 
Forms. Visual Studio .NET • Implementations sur le poste de travail. Behavior Internet Explorer. Ecmascript avec 
Mozilla. Office XP en client SOAP. Macromedie Flesh. . Le defi de I'interoperabilite. Tests SOAP, UDDI et WSDL. 
Le consortium WS-I . INFRASTRUCTURE DES SERVICES WEB . Fiabilite des echanges: HTTPR, WS-Reliebility... 
• Gestion de la securite: XML Encryption. XML Signature. WS-Security. Exemple avec X.509 • Gestion des 
transactions: WS-Coordination, WS-Transaction, BTP • Gestion des processus metier en BPEL, WSCI... • ETUDE 
DE CAS • Agence de voyage. Implementation client en IE. Architecture statique: Implementation en Java. 
Architecture dynamique (UDDI). Implementation Java • Implementation mixte Java/.NET • Architecture en pro- 
cessus metier: orchestration de services en BPEL. 
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A qui s'adresse cet ouvrage? 

-Aux developpeurs d'applications, en particulier a ceux qui utilisent les environnements J2EE et .NET. 

-Aux architectes des systemes d'information, tentes par les architectures orientees services (AOS). 

-Aux decideurs, consultants, chefs de projets et specialistes de ^integration, qui ont besoin d'etendre leur capacite 

d'intervention vers I'urbanisation et I'ouverture du SI de I'entreprise. 
-Aux etudiants des ecoles d'ingenieurs et universitaires, qui recherchent une reference sur I'architecture orientee 

services et les technologies de services Web. 

Poursuivez votre lecture sur le Web 

- telechargez le code source des exemples et etudes de cas ; 

- telechargez le glossaire et les mises a jour. 
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